This reminds me of the time we wanted to ride the Amtrak Coast Starlight from Seattle to San Jose on our trip to the US in 2014. It's supposed to be a scenic route, and takes about 24 hours for that leg. (The train carries on to LA IIRC.)
When we got to the station in Seattle and checked in our bags they told us the train was at least 5 hours delayed, so we should go do something else for 3 hours and then come back for a status update. We also left our mobile number and email address with them in case there was anything else. (Though in theory they should already have had these from the ticket booking.)
Anyway, we went off to a café round the corner (it was an apparently rare snowy day in Seattle - hence the delay, plus we didn't want to stray too far) and had some drinks and brunch.
After about 2 and a half hours later we wanted to stretch our legs and wandered back to the station. Whereupon we were told the train had already left without us… but with our bags, but we could have a refund or take the train on a later day. ️
We only had overnight bags, and an onward journey planned the other end, plus we were now super annoyed so we ended up scrambling to find a flight that would get us there by the next day. That was the closest to the flight time I've ever bought an airline ticket, less than 3 hours I think. It worked out OK in the end, we got our bags from San Jose station the next morning as we'd beaten the train there, though the contents of one of the bags was damaged from rough handling.
While unfortunate, this has been the case since Ryzen launched. Ryzen 2000G(E)/U series were Zen-based like Ryzen 1000(X), Ryzen 3000G(E)/H/U series were Zen+-based like Ryzen 2000(X), Ryzen 4000G(E)/H(S)/U is Zen2-based like Ryzen 3000(X(T)).
I suspect they do this because the APUs typically launch half a year after the GPU-less variants and
What's really confusing and unfortunate is that there are some Ryzen 1000 series variants (Ryzen 3 1200, Ryzen 5 1600) that were re-released well over a year after their initial launch and which are actually Zen+ based.
Of course, modern iPhones and iPads actually come with fully fledged NVMe SSDs. So it's not really clear why that decision hasn't been revisited - or why Apple hasn't at least introduced some kind of process hibernation which fully restores background processes when switching back.
Anno 1800 might float your boat? Or any of the previous games in the Anno series for that matter. The campaign does very much have a story and specific objectives, but the interesting bit is the regular sandbox game:
Turn off pirates and competitors, and either turn off or ignore NPC quests. (There's no penalty to ignoring them, but they sometimes can be useful if you need money.) You'll still have incidents like fires, industrial explosions, disease, and riots, but those are influenced by factors you control, and with well-placed fire stations, hospitals, and police stations you can very much contain them so they're a non-issue.
Sorry, can you elaborate? Apple's "A" series CPUs have been out-of-order for years and at least a few years ago had a similar superscalar/ooo structure to Intel's Haswell chips. (Apple poached a bunch of Intel processor designers…)
> Does it though? It’s a rare edge case that should be trivial to solve with minor human intervention.
Apparently[1] centenarians make up 0.02% of the UK population; how well this statistic transfers to EU nationals in the UK I don't know, but if it's 1:1 then this issue affects about 600 people. A large proportion of those will however have some trouble rectifying the problem themselves; the over-90-year-olds I know certainly would all struggle with this sort of thing. In the article, the activist who volunteers helping people with the registration process is quoted as saying it required 2 calls to the Home Office. This is someone who presumably has some practice dealing with the process and the Home Office and they couldn't get it sorted out trivially. If it's an accepted failure case of the automated process, there needs to be an established alternative process; it sounds like no consideration was given to this edge case at all. So, not "minor human intervention."
If by most, you mean >50%, then you're probably right, but but especially within EU countries, having >10% foreign nationals among the population is common. Those foreign nationals will frequently give birth to equally foreign children, who need to obtain passports whether or not they're planning to travel. (Although they frequently do travel to visit family.)
> This is bizarre, blame the passport for only having the last two digits and not the computer reading it.
I mean, the passport only showing 2 digits is worth mentioning. But I doubt this 101-year-old got much choice in exactly what format his passport contained his DOB - so the software needs to handle it. So if in doubt (e.g. both possibilities yield an age younger than oldest person on the planet) the software should be asking to confirm the century.
If you want to get really fancy, check the issue date first. If this is before the supposed 20xx birth date, the birth date must actually be 19xx. People aren't issued passports before they are born.
DriverKit has only been around since 10.15 so currently it's not easy to correctly support a range of versions with everything so massively in flux and Apple's aggressive deprecation schedule. Writing and maintaining macOS system level software (including drivers, etc.) has generally become a pretty big headache since around 10.13, stuff is constantly breaking due to OS changes and regressions.
This obviously always happened to some extent, but the pace of breaking changes and bugs picked up massively around that time - I think a large part of the problem is that Apple's own developers don't actually need to use any of these features themselves, so they are just dumped onto 3rd party developers in a half-arsed state. I'm thinking of kernel extension authorisation (which was super buggy in earlier 10.13.x releases and still has weird quirks), various user consent additions (there are no APIs for directly checking or prompting for many of the permissions, let alone notifications when the user grants or revokes consent), DriverKit, EndpointSecurity, etc.
Someone else on the project experimented with FileProvider during the Catalina beta, so this is all second hand, but it wasn't really suitable for the job - it seemed more designed for having a special folder like the iCloud Drive, and didn't work well with CLI tools. I actually didn't realise it was pulled before the Catalina launch, but that makes sense, I got the impression it was nowhere near production ready.
If you are relying on the ability to develop and load specific types of kext in macOS in future, I recommend getting in touch with Apple DTS. (Note that communications with DTS are unfortunately typically under NDA.)
VFSForGit is/was not a true file system, it just intercepts file I/O events to dummy files to lazily fill them with content and to log writes so that 'git status' does not have to scan the whole repo for changes.
The macOS port uses the KAUTH listener API, which was indeed deprecated with 10.15.
I was the external contractor brought onto the project as the project's macOS kernel extension expert; my contract expired in November after the port was put on ice. As far as I'm aware it's no longer being pursued, with sparse checkouts being the new hotness.
I don't want to and can't speak for Microsoft, and I did not make the final decision, but:
* The user space alternatives (NSFileProvider, EndpointSecurity) are not up to the job for various reasons.
* Porting everything to the much more involved VFS KPI would have been a large amount of work, and with a near-100% risk of having the rug pulled out under it yet again.
Probably because importing Mach messaging and VM APIs into the Linux kernel, and recreating IOKit and similar from scratch is a pretty major undertaking; the APSL isn't GPL-compatible, so using the existing XNU code and trying to make it fit into the Linux kernel isn't something that could ever be upstreamed. Aside from the fact that Linux's device model doesn't exactly map to IOKit well.
Then there are invariably plenty of assumptions that userland makes: launchd is probably assumed to have PID 1; all sorts of stuff like that.
Plus of course, there's the question of whether this would be inline with the EULA of Apple's userland…
There's always GNUStep if you want to write Cocoa apps in Objective-C on Linux. Somehow I have a feeling the APIs aren't what's been holding back Linux on the desktop.
Only reselling already implemented stuff is neither software engineering nor what I love.
$240k would be a highly respectable income pretty much anywhere in almost any field. In most of the world, doctors are paid less than that while routinely working night shifts and constantly making life and death decisions about their patients, and you’re seriously complaining about being paid $2k/day for fiddling about with stuff on a computer?
the whole comment section was insisting that per-project billing is the only viable way to make money in consulting.
Generally, when someone gives you advice that's supposed to be 100% right in all cases, they either stand to gain from it personally or have no idea what they're talking about.
In this case, the difference between the two approaches is mostly a question of who ends up with what risks. My wife and I run a two-person development contracting business, and we've done projects with both approaches. Both have worked well for us, but for the type of work we tend to do, most projects would not be suitable for fixed price billing.
The reason is that most of our work consists of "deep dives" for figuring out if something is possible at all. (Or more precisely, possible within a reasonable amount of effort.) So what usually ends up happening is we'll agree on a capped research budget, and dig into the problem up to that number of days. If we find a solution before that time, great; if we find a fatal blocker before that time, well, not great but it's a result. Otherwise, we'll hopefully have found some leads to pursue in that time and can give a better estimate for how much more effort it'll take.
Maybe it's possible to do this sort of project on a value-based basis, but I certainly haven't found one that seems fair, or that a client is likely to accept. The author of the original article likes to claim that with value based pricing, interests are aligned. Well, for this sort of project, one of the parties is likely to lose out massively if you agree a fixed price up front.
And as for the author's assertion that your income is capped: you have one variable you can tweak: your rate. Charge more! We charge more than his "optimistic estimate". Sure, we're still not rolling in it, but we also don't work anywhere near 40 hours a week. And the implication that our incentive is to drag out projects to get more billable hours - well, I have a stronger incentive to make all my clients super happy so that they keep coming back for repeat business. This way, we have more requests coming in than we can feasibly accept.
Of course, only touch open ended projects for savvy clients. The nature of our particular specialty means we work with tech companies who understand the nature of big unknowns in projects.
Additionally, you have artists and level designers working on these files. These people tend to be semi-technical, and confronting them with the full details of git is usually met with a lot of resistance.
I know some smaller studios that use git to some extent, and they tend to struggle with it on occasion - again, primarily in the art & design departments, mainly with binary files. All the larger studios and some of the smaller ones seem to use perforce. Publisher-owned multinationals might have their own proprietary systems, I don’t have any insider information there.
In any case, people who aren’t familiar with the requirements of gamedev like to argue about this. It’s like proponents of forks arguing with someone trying to eat soup with a spoon.
When we got to the station in Seattle and checked in our bags they told us the train was at least 5 hours delayed, so we should go do something else for 3 hours and then come back for a status update. We also left our mobile number and email address with them in case there was anything else. (Though in theory they should already have had these from the ticket booking.)
Anyway, we went off to a café round the corner (it was an apparently rare snowy day in Seattle - hence the delay, plus we didn't want to stray too far) and had some drinks and brunch.
After about 2 and a half hours later we wanted to stretch our legs and wandered back to the station. Whereupon we were told the train had already left without us… but with our bags, but we could have a refund or take the train on a later day. ️
We only had overnight bags, and an onward journey planned the other end, plus we were now super annoyed so we ended up scrambling to find a flight that would get us there by the next day. That was the closest to the flight time I've ever bought an airline ticket, less than 3 hours I think. It worked out OK in the end, we got our bags from San Jose station the next morning as we'd beaten the train there, though the contents of one of the bags was damaged from rough handling.