Yeah, people forget the degree to which sysvinit was hated at the time - "why are you forcing me to deal with an impenetrable forest of symlinks rather than simply hand-edit a couple of basic rc scripts?!?".
If the intention is to create a system that users can reason about, then sysvinit offers the worst of all possible worlds.
> why are you forcing me to deal with an impenetrable forest of symlinks rather than simply hand-edit a couple of basic rc scripts?
Run levels. That's it, sysvinit is about run levels. Each run level starts or kills off its own specific list of runnable things like applications, daemons, capabilities, etc.
Run levels were a desirable feature back in the day amongst System V Unix vendors, so each run level required its own kill and start scripts for each item. Run levels, for example, could take a running system from single user (root admin) mode to multi-user, multi-login, NFS sharing, full X11 mode in one command immediately as the scripts ran. This allowed rapid reconfiguration of a system, such as from a GIS workstation to a headless file server, etc. etc. as needed. Each system could be configured to boot to a specific run level. Rather than duplicate some or all such scripts across some or all run levels, symlinks were the solution.
For example, Solaris had run levels 0 through 6. Zero was a blunt force system halt; 1 was single root user admin mode; 2 was multi-user headless mode with NFS; 3 was multi-user X11 windows mode with NFS; 4 was unspecified and therefore kept for purely local configuration as desired; 5 was a planned, orderly system shutdown; and 6 was a planned, orderly system reboot. The root user could implement their choice of run level directly with the init command.
Each run level had its own run control directory (rc.d) under /etc/rc.d for its appropriate kill and start scripts, which were run in order of their K or S number, so dependencies had to be kept in mind when numbering, and curing a dependency failure was as simple as changing a script's number to rearrange the list. So, why copy S04blahblah from rc2.d to rc3.d when a symlink is far better?
Its not hard to understand when you get the big picture, and it wasn't hard to administer if you had the proper overview of it all. Admittedly, admins coming in cold would have to sort through it all, which is partly why it gained a reputation for murkiness when not properly documented by/for local admins. Keep in mind it was the era of administering sendmail macros and NIS tables by hand and you get the picture.
And that's... fine. They're still giving away their code, and anyone is free to step up and mke sure that it builds or that internal dependencies are replaced.
And it's a completely standard situation for non-corporate open source software, too. OpenSSH, for instance, has OpenBSD-specific dependencies and can only be run on Linux because of the porting efforts by a separate group of volunteers.
Sure, it'd be event better if they went out of their way to facilitate external participation, but they don't have to. Not even GNU does so for everything they publish!
tl;dr: There's a spectrum of FOSS varying from performative crap to usable.
You're conflating the differing treatment of projects where there is much investment and community usability like react, ones that are half-assed like edenfs, and the zillions of others that aren't even explained clearly what they do or what they're for.
> anyone is free to step up and mke [sic] sure that it builds
On thrown-over-the-wall projects, there's too many inside-baseball gotchas and little/no documentation. Effort by others are generally unrealistic and a waste of time that won't be merged since there are rules and limitations for community contributions. The vast majority of tiny and obscure projects, MAANG code is useless to average people working on average problems because the burden to make it work is as much or more than reinventing it themselves.
> or that internal dependencies are replaced.
This is hand-waving away reality. No average engineer for reasonable effort is going to be able to reproduce an undocumented API for unreleased kernel extensions/FUSE/etc. for Mac, Windows, and Linux to make edenfs work.
Another case in point: Hack. No documentation and no portable build instructions/toolchain.
React and react native are in a different class where there is meaningful community participation and investment. Whereas hack, edenfs, and chef cookbooks is/was mostly thrown-over-the-wall stuff. There are a few projects in the middle like watchman that update code using an opaque internal->external export process without a whole lot of documentation or clear changelogs, but it's still semi-useful.
The spirit of FOSS is cheapened by flooding the zone with too much stuff on the side of crap. It's better to release less stuff that's well-supported with meaningful community engagement rather than create noise. But if you're fine with a blizzard of noise that isn't useful to anyone else, that's cool for you. Everyone is free to do what they want to do, even if it's trying to make partially-released stuff work when it would've been faster to rewrite from scratch.
If Waymo didn't exist, we'd instead be lauding the progress of Wayve, Pony, and WeRide.
At this point, Tesla have the potential to be at best maybe #5 globally. No wonder they're so desperate to hide behind a tariff wall in their home market.
I've had a similar career, and the only time I've ever been asked about my education was towards the end of the hiring process with a major US-based tech company back in the early 2010s.
No UK employer has ever asked about it, to my knowledge.
I've always found levels.fyi to be a little pessimistic for the UK when compared with commercially-available benchmarking services.
I suspect it's because people on PAYE tend to think of their basic salary + bonus + income tax, but disregard NICS, pension, paid holidays, and other benefits. They end up reporting a total package that's 10-20% lower than it actually is.
Not so much of the "long term vision and plan", but plenty of aligning stakeholders, as well as discovering, researching, and managing third party resources - and then there's the requirement to run the service for a further 18 months.
£4m is enough to pay for about 15 consultants for 18 months at typical rates paid by the public sector. But since this is a standalone project, call it a dozen plus overheads. That feels roughly right as a finger-in-the-air estimate for a project of that sort of scope.
It's actually the role of Police and Crime Commissioner that prevents them from being an MP simultaneously. In Greater Manchester (and London) the PCC role is combined with that of Mayor, but it isn't in most other city regions.
There's not much actual difference in the mayoral aspect of the roles - Jarvis was the Mayor of the South Yorkshire Combined Authority, not simply the mayor of Sheffield City Council.
It was a similar story with Pulseaudio - it caused pain for early adopters but, by the time that Debian stable switched to it by default, almost all of the issues and corner cases had long since been worked out and it was almost completely trouble-free.
Mind you, the libc5 -> glibc2 upgrade was pretty horrible in Debian land, so they didn't always get it right in the early days...
It's pretty common to treat unauthorised entry attempts as a serious security incident.
The minimum follow-up actions I'd expect would be filing a police report, sending all-staff emails reminding people to be on the lookout for tailgaters, and reviewing security at reception.
If there was a specific risk of ongoing intrusion attempts, then I'd also expect legal action (eg. injunctions or restraining orders) to be taken in mitigation.
It's perfectly reasonable for staff to want to seek assurance that those sort of basic measures to ensure their safety are underway.
If the intention is to create a system that users can reason about, then sysvinit offers the worst of all possible worlds.
reply