It did, but it was taken from OpenSolaris and ported to a number of platforms, notably FreeBSD and IllumOS (OpenIndiana, SmartOS, Nexenta), and also Linux. The featureset, integration and and usability on Linux is poorer than the rest. Though it works well, it's better on the others.
Is it? After repeated dataloss using it with raid 0, 1 or none at all, plus other problems like becoming unusable from getting completely unbalanced, I'm a bit shy about trusting it quite so readily. It's hard to say it's "fine" when in all cases it was "fine" right up until the point it was "not fine" and lost all its data or went read only. "Working" isn't a useful observation for a filesystem; validating that it copes with every conceivable failure case by having the test cases to do that would, but it's been clear from all the failure scenarios I've encountered that this is missing. While the worst dataloss bugs have been fixed, it doesn't provide confidence that others remain lurking in there, or if regressions occur and reintroduce bugs. Btrfs continues to be a gamble which is not where you want to be when you care about data integrity. One of the reasons I switched to ZFS two years back. Once bitten, twice shy. But I've been badly bitten by ZFS on several occasions...
ZFS can be more intelligent though, since it has more information about what the data means, rather than simply looking at raw blocks. If you have a copy count greater than one, it can use the redundant copies in addition to the mirrors or raid parity to self-heal. It can also ignore errors when it's in an unused block; that would otherwise be an error since there's no way to know the block is unimportant.
LZ4 is performant, since it was intended to trade off compression efficiency for less CPU and memory usage. And is cleverly run multiple times over the same data to improve the compression, then bail out once it's no longer worth repeating. But some of the other options have terrible performance; gzip is dire, and gzip-9 barely usable. When I tried benchmarking these a few months back, they nearly tanked the server by making the filesystem nonresponsive and pushing the CPU utilisation through the roof copying a few hundred gigabytes of data (FreeBSD 11). LZ4 in comparison is barely noticeable--it's definitely the best choice.
Ubuntu, works out of the box since 16.04. Additionally, while it's not supported by the installer, you can set it up to boot directly from the pool with GRUB. Other implementations such as in FreeBSD remain better integrated and more featureful and usable, but you can use it today on Linux without any special effort.
No need to speculate. Lookup Nyquist-Shannon sampling, e.g. https://svi.nl/NyquistRate. The sampling frequency must be twice the maximum spatial frequency being sampled. This also applies in reverse on image reconstruction (display). The pixel frequency should be double the maximum spatial frequency the eye can detect, in order to avoid high frequency aliasing artefacts. Anyone complaining that "they can't see the pixels" clearly misunderstands the basics of digital imaging! Not being able to see them is the ideal situation, but up until now we have usually had to compromise unless viewing at a distance.
Modern printers don't use Epson ESC/P or any other traditional imperative escape code-driven control. ESC/P hasn't been used by mainstream software directly since the end of DOS style word processors. At best, newer stuff would just use the control codes to do single/double/quad density raster printing. They are now either dumb, basically accepting a raw bitmap or equivalent to drive the print head, or they accept PostScript/PDF/PCL. It's been that way since the dawn of scalable type (DR GEM used Type 1, MS Windows with TrueType, MacOS).
The only place I've used ESC/P in the last two decades was for point of sale software, driving receipt and label printers, including barcode printing, and also dot matrix output for billing. But obtaining printers which supported it, even from Epson, was difficult 12 years ago, so not sure what it's like today. Most of their stuff from the last decade dropped ESC/P support entirely; it's all REMOTE mode which is basically going back to those giant bitmaps. It's all in the client-side driver for the most part. (I used to be one of the printer driver maintainers for Linux.) It does exist, but it's in custom niches with software written to drive specific hardware.
Windscale wasn't a power reactor, and used horizontal channels with forced air cooling. It's no accident that the later reactors are not air cooled but CO2 cooled and have vertical channels to allow passive convection if the circulation shuts down.
They have, but not at the small scale required.
I've tried to find a link for this but can't. When I was chatting to a specialist concrete engineer, he mentioned that some reactors use digital electronics embedded into the reactor walls. Transistor junctions are created from ceramic pieces wrapped/plated with gold, which are then further encased in ceramic and then embedded in the concrete walls. This is mega-electronics rather than micro-electronics, operating at very high voltages, so you can't have that much logic due to the limited space, but for simple but safety critical stuff in high radiation environments this is so large it's not significantly affected by radiation and radiation damage as it is on a small scale.
Where "everything" is a light water reactor such as the BWRs and PWRs of this period, it certainly looks like that's the case. That isn't universally true though; the graphite-moderated Magnox and AGR designs of the same era can passively cool entirely by CO convection. The downside is they have a lower power density, but the only failure I've read about was a partial melt of a single Magnox fuel rod after a blockage in a single channel interrupted the airflow.
A runner is a job scheduler running on a remote host, which can be your own machine or hosted wherever you like. When you push a branch or open a merge request etc., you can have it trigger builds on any registered runners (you can have as many as you like).
A workspace is a place to store stuff resulting from that build such as libraries, binaries, documentation etc. This means that you can have a CI workflow and deployment hooked directly into the merge request and code review process.
This stuff also works at a higher level than github. With github, travis and other CI builds are tied to a project. With gitlab they can also operate at the level of an organisation, so you can use workspaces to test multiple projects in sequence, so that you can do CI and deployment stuff across multiple repositories to test all downstream dependencies or whatever you need to do.
It's all documented on the gitlab site. I'm still in the early stages of trying all this stuff out myself.
GitLab does a bunch of stuff which GitHub doesn't. The most significant for me is the integrated CI, and that you can host your own runners and workspaces on your own infrastructure (or some cloud provider). Compared with Travis or some other CI hook on GitHub, this is vastly more flexible and powerful.
I also find the ability to assign people for review, milestones and such on issues and merge requests to be very nice features which GitHub lacks.
It is a GitHub clone, but they seem to have taken the lead in implementing more advanced functionality. At work, we're currently looking into a trial of GitLab plus our own multi-platform CI runners as an alternative to GitHub+Travis and internal Jenkins with several hundred jobs. It stands to greatly simplify the amount of failures, admin time and developer time keeping that lot going.
Same underlying codebase, yes. But it's integrated into the system much better on FreeBSD. On FreeBSD, I can use the full NFSv4 permissions model; on Linux it's restricted to standard permissions and maybe also POSIX ACLs mapped to NFSv4 ACLs (not sure if it's functional). With a suitable NFS or CIFS client, those extended ACLs are available and useful on client systems as well. On FreeBSD any user can run the zfs, zpool and other commands with proper permissions control over actions which may be performed. On Linux, these all require root. On FreeBSD, it's also possible to delegate admin permissions on a per-dataset basis, e.g. to allow a user or group to snapshot and clone, send and receive datasets. None of that works on Linux. On FreeBSD, I can set the sharenfs properly and immediately get a dataset (and all its child datasets) recursively exported. Doesn't work on Linux.
Those are just the few I noticed. If you want to use ZFS seriously, FreeBSD gives you a much more useful environment; Linux needs to better integrate it at several levels to bring it up to the same place. Linux sorely needs NFSv4 ACL support in the VFS for starters; it would also make NFSv4 vastly more usable.
NFS is still broken for me (Ubuntu 16.10). Fails to mount on startup almost every time; sometimes it succeeds but the chance is about 1 in 10. Some race I guess, but who knows? It's too much of a black box to easily debug. With sysv-rc, I could step through every script by hand, and pinpoint a failure to the line.
Contrast that with the "old" FreeBSD and Debian systems using BSD init or sysvinit. They manage to mount the NFS filesystems reliably, every damned time. Which is of course what I'm looking for. Is reliable startup too much to ask for?
There's also another factor to the migration which is familiarity.
Moving from a pre-systemd to a systemd Linux system fundamentally changes many aspects of system administration and maintenance, not just because of the init system replacement, but also from the replacement of all the other tools which systemd absorbed or replaced, or made mandatory. While FreeBSD has its minor differences, a contemporary BSD system is significantly more similar to a pre-systemd Linux system than a systemd Linux system. I personally feel more at home there (it's very similar to a traditional Debian system in many respects), and that my 2+ decades of Unix expertise is as relevant there as it ever has been.
I'm not a Luddite, but change for the sake of change isn't automatically a good thing, and while systemd has some good ideas, the design and implementation of the thing leave a lot to be desired. There doesn't seem to have been as much consideration towards backward compatibility of interfaces and configuration than could have been achieved. Linux was a mature platform, and you don't go around making gratuitous incompatible changes to such systems. At least, not without major fallout, which we continue to see.
This behaviour is where I really dislike the sytemd way. The "it will be done this way, and only this way" attitude. It's my system, why should I not be the one who gets to decide policies such as this? In the initscripts world, this would have been effected through a little configuration file in/etc/default, which would customise the behaviour of the script (or you could edit the script as well if you wanted something truly custom). While systemd does allow some modicum of customisation in the unit files, there's a heck of a lot of policy and behaviour directly encoded in the implementation, which an admin isn't going to be able to touch without rebuilding the thing. While old and crusty, sysv-rc and initscripts left every part out in the open and hence amenable for changing and tweaking. So the "don't boot if a single filesystem in fstab fails to mount" policy would have been a tweak to the mountall script (or better, one of the mount helper shell functions).
I used Linux exclusively from the mid-90s until almost exactly two years back. I was aware of the BSDs, occasionally read about them and once installed it for a few hours just to see, but never had any real reason to bother with them. Seemed like it would be a lot of pain for a worse experience, particularly when you had to build all the ports and cope with worse hardware compatibility.
One of my work colleagues is a long-time Debian user. For the last 18 months, his servers are running OpenBSD.
When it came time to upgrade from wheezy to jessie, I had the option of futzing with the system to retain or reinstall sysvinit, but since it's clearly not supported properly and several key packages deliberately depend upon systemd, you get an inferior experience which is likely to continue to regress. So I looked at FreeBSD, anticipating it would be awful. However, what a revelation. With the new pkg tool, installing and upgrading packages is on a par with apt, and with 25000 packages, it's rare to find anything missing, being at least as comprehensive as the Debian archive. It's also gratifyingly up-to-date for the most part, and if you track the weekly (rather than default quarterly) builds, you're pretty much always up to date with the tools you need (e.g. cmake, clang for me). And then there's ZFS, the "killer feature". Absolutely superb, and really well integrated; vastly easier to use and more featureful than the Linux port. This alone makes it worth using for archiving and serving files.
While there are plenty of people who cope with systemd, or even like it, it's spurred an awful lot of people to step out of the "comfort zone" of Linux, and take a proper look at the alternatives. For some of us, it's been an eye-opener to see just how capable those alternatives are, and we've not looked back.
sysvinit (low-level process spawning and runlevel change triggering; all done from/etc/inittab)
sysv-rc (intermediate-level script to effect runlevel changes by batch invoking rc.d scripts)
initscripts (high-level rc.d scripts to do the actual work of bringing the system up or down, with helper scripts to unify logic shared between multiple scripts)
package-specific scripts whch use the initscripts helpers and to some package-specific action
insserv and startpar, to use LSB script headers to compute a global dependency graph with make-like syntax and allow sysv-rc to start the scripts up in parallel with proper dependency constraints
Not only is it modular, the system is fully composable, allowing the admin to build each layer upon each layer to their own liking. The layers are not tightly-coupled, and it's entirely possible to replace any or all of the layers:
You can swap out sysvinit but retain sysv-rc and all higher-level parts; example: s6
You can swap out sysv-rc; example: file-rc which gives a bsd-style startup with a single file to configure what starts, or daemontools which runs directly from inittab and does process supervision
You can replace the initscripts with whatever you like, but retain sysvinit; example: openrc, which replaces sysv-rc and uses its own scripts
When people complain about sysvinit being old and outdated, these claims are usually considering the sysvinit+sysv-rc+initscript triad as a single entity. sysvinit is old, but it's a tool with just two purposes: running specified programs and runlevel switching. You can build anything you want on top of that. It does exactly what it was designed to do, and *only* what it was designed to do. It's not broken, and never was. If you want more functionality, you build that on top of it.
Some parts of the old system were crusty, for example dynamic networking configuration. But the vast majority worked pretty well, and pretty efficiently. And it would have been perfectly possible to fix those issues, with vastly less effort and disruption than throwing it all away and breaking much backward compatibility in the name of inter-distribution uniformity (and consequent stagnation).
Note that while common distributions came with their default, it was absolutely possible to run with all sorts of different combinations of components; Debian supported several. file-rc was a supported alternative to sysv-rc, and daemontools and other alternatives were also available. It's this very flexibility which allowed systemd to be swapped in relatively easily. But consider that once systemd was adopted, the vast majority of this flexibility was lost. The low-level init, the rc runner and the initscripts are all in one place, and it's no longer possible to swap one part for another or tweak one little bit. It's all or nothing, and that will effectively entrench it. As an ex-Debian sysvinit/sysv-rc/initscripts maintainer, I wasn't dictating that you use them all together. You want to use openrc, or daemontools or s6? Go for it, you don't need me to approve it, you do what you like. Want to change the initscripts around to do something different, be my guest. We took care not to break any custom setups on upgrade as well, e.g. preserving file-rc configuration when adding/removing/upgrading packages, as well as helper script API stability. Contrast that with the top-down dictatorial approach which comes from the systemd people: you'll use the system the way we tell you to, and no, we don't approve of you doing anything non-standard unless we like it (and good ideas only come from us, so forget it). And if you do change stuff and it breaks, that's 100% your fault since we don't care to consider this. That's the real difference, the attitude and thought behind the design, and how that affects your freedom to use your system as you see fit. And that's one major reason why my servers now run FreeBSD.
Why would it be desirable to run bash on Windows 10 when I'm going to get a better experience using bash on anything else be that Linux, BSD, either native or virtually. I can understand for some people this might be their only choice, but that doesn't make it good, it's just making the best of a bad situation. If they want me to try it, they'll have to make it better than on Linux, not just "good enough to ship". Because if I'm going to use Windows 10, it had better have some concrete benefit given all its massive downsides.
Agreed. You can enhance an image correctly if that processing only makes use of information in the original image. For example, deconvolution, despeckling, contrast enhancement. These change the image, but the process is either neutral (no information loss) or lossy (some information loss). You can't *add* missing information to an image, because that implies making assumptions about the image which are likely to be incorrect for most cases. Validating such assumptions are correct is extremely difficult.
In the case of the google filtering, this is fine if it's purely for aesthetic purposes, but definitely not if it's used for any serious purpose. In the domain I work in (scientific and medical imaging), this would be classed as fraudulent misrepresentation of data, and would get you fired. In fact, a member of my faculty was fired just last week for academic fraud after being discovered to have been misrepresenting their image data over their whole career--it's taken extremely seriously.
I'm well aware of the history and context. It was quite clear that a replacement would be welcome, providing that replacement was an improvement. I was initially quite hopeful when systemd came about; but it's proven to be unsuitable. There's more to software than features alone, and for this low level part of the system, it's critical to the system's functioning for it to be defect free. It has some interesting ideas, but the design and implementation leave a lot to be desired.
sysvinit (or any init) does not need to have a lot of features, so long as you can build more complex features and functionality on top. The very essence of modularity and substitutability. The priority is to be minimal, reliable and bug free. Just look at how many other systems run more advanced stuff on top of sysvinit. It doesn't have to be there in PID1 or provided by the same software package. sysvinit had a very clearly-defined role and within that constrained scope, it provided a working robust solution that worked for multiple decades. The design of sysvinit can be described in a couple of paragraphs of text; you'd need a book to describe systemd, and I doubt even the authors could fully describe it themselves. Overcomplexity and poor design has a cost, and systemd is already an unmaintainable mess.
The very fact that it had a small interface (signals, initctl, inittab) meant that it could very easily be replaced by other systems (and this was done multiple times). The fact that it was easily built upon meant that there were multiple systems built on top of it. It wasn't perfect, and it didn't have every feature everyone wanted. But the point is that it didn't have to while it could be used as a building block by others. systemd is at one extreme (large, complex, tightly-coupled) while s6 is at the other (tiny, simple, loosely-coupled); sysvinit is toward the s6 side of the spectrum; were I writing it from scratch, I'd lean more towards s6 and strip out the more complex bits into separate parts; PID1 doesn't need to deal with inittab for example, nor with runlevels or shutdown.
The core C code of sysvinit was feature-complete, reviewed, debugged and tested years and years ago. Its original design goals were satisfied, and the project is "done". Software does not need continual churn to mark it as "maintained". The same applies to startpar/insserv and other ancillary bits. If you found a bug in sysvinit, I'd review and test it, and push a commit for it. I no longer maintain the Debian packaging, but I still have upstream commit rights should I need them.
Compare this with systemd. It doesn't have the same clearly-defined scope; it's not possible to say when it will be complete as a result. Software can be complete and finished.
That really depends upon how independent the "independent" studies are, and exactly what they were looking at.
When I was a Biology undergraduate in the late '90s I got several haranguing lectures by various researchers about GMOs and how awful it was that people were against them, how safe they were and how they were the experts and knew they were fine. I later checked, and they were funded by Monsanto, Novartis and other big agribusinesses. Being funded to do fundamental research by big companies can introduce bias, and in some cases it's quite unsubtle.
The big problem I have with claiming something is "safe" is that it's often in a very narrowly-defined and short-term scope. In the case of GMOs, that's often limited to "safe for human consumption" ("because we fed it to rodents for a few years with no ill effects" or similar). What about the effects upon people and the environment in the long term (many decades)? Contamination and change to wild populations of the same organism, for example.
The problem I have with it is that it's easy to prove something specific is safe while ignoring the bigger picture. We were assured that glyphosate was safe for bee populations. It had been tested in the lab and we knew its toxicity precisely. But it later turned out that at sublethal doses it screwed up their navigation leaving them unable to make it back to their hives. That hadn't been investigated, and that was an important part of the bigger picture. It wasn't toxic but it was still deadly.
When such important glaring omissions are made, which could potentially destroy our agricultural productivity, leading to starvation and civilisational collapse at the extreme, it also makes you wonder what important but uninvestigated aspects there are in all areas of science. GMOs might be "obviously safe" to the intelligentsia of the present, but who knows if it will be quite so obvious in 30 years time if some fatal flaw is discovered. While it's clearly profitable today, and it might well be safe, it doesn't hurt to have a sensible amount of caution when our entire population is critically dependent upon this stuff for our continued survival.
Slashdot Mirror
It did, but it was taken from OpenSolaris and ported to a number of platforms, notably FreeBSD and IllumOS (OpenIndiana, SmartOS, Nexenta), and also Linux. The featureset, integration and and usability on Linux is poorer than the rest. Though it works well, it's better on the others.
Is it? After repeated dataloss using it with raid 0, 1 or none at all, plus other problems like becoming unusable from getting completely unbalanced, I'm a bit shy about trusting it quite so readily. It's hard to say it's "fine" when in all cases it was "fine" right up until the point it was "not fine" and lost all its data or went read only. "Working" isn't a useful observation for a filesystem; validating that it copes with every conceivable failure case by having the test cases to do that would, but it's been clear from all the failure scenarios I've encountered that this is missing. While the worst dataloss bugs have been fixed, it doesn't provide confidence that others remain lurking in there, or if regressions occur and reintroduce bugs. Btrfs continues to be a gamble which is not where you want to be when you care about data integrity. One of the reasons I switched to ZFS two years back. Once bitten, twice shy. But I've been badly bitten by ZFS on several occasions...
ZFS can be more intelligent though, since it has more information about what the data means, rather than simply looking at raw blocks. If you have a copy count greater than one, it can use the redundant copies in addition to the mirrors or raid parity to self-heal. It can also ignore errors when it's in an unused block; that would otherwise be an error since there's no way to know the block is unimportant.
LZ4 is performant, since it was intended to trade off compression efficiency for less CPU and memory usage. And is cleverly run multiple times over the same data to improve the compression, then bail out once it's no longer worth repeating. But some of the other options have terrible performance; gzip is dire, and gzip-9 barely usable. When I tried benchmarking these a few months back, they nearly tanked the server by making the filesystem nonresponsive and pushing the CPU utilisation through the roof copying a few hundred gigabytes of data (FreeBSD 11). LZ4 in comparison is barely noticeable--it's definitely the best choice.
Ubuntu, works out of the box since 16.04. Additionally, while it's not supported by the installer, you can set it up to boot directly from the pool with GRUB. Other implementations such as in FreeBSD remain better integrated and more featureful and usable, but you can use it today on Linux without any special effort.
No need to speculate. Lookup Nyquist-Shannon sampling, e.g. https://svi.nl/NyquistRate. The sampling frequency must be twice the maximum spatial frequency being sampled. This also applies in reverse on image reconstruction (display). The pixel frequency should be double the maximum spatial frequency the eye can detect, in order to avoid high frequency aliasing artefacts. Anyone complaining that "they can't see the pixels" clearly misunderstands the basics of digital imaging! Not being able to see them is the ideal situation, but up until now we have usually had to compromise unless viewing at a distance.
Modern printers don't use Epson ESC/P or any other traditional imperative escape code-driven control. ESC/P hasn't been used by mainstream software directly since the end of DOS style word processors. At best, newer stuff would just use the control codes to do single/double/quad density raster printing. They are now either dumb, basically accepting a raw bitmap or equivalent to drive the print head, or they accept PostScript/PDF/PCL. It's been that way since the dawn of scalable type (DR GEM used Type 1, MS Windows with TrueType, MacOS). The only place I've used ESC/P in the last two decades was for point of sale software, driving receipt and label printers, including barcode printing, and also dot matrix output for billing. But obtaining printers which supported it, even from Epson, was difficult 12 years ago, so not sure what it's like today. Most of their stuff from the last decade dropped ESC/P support entirely; it's all REMOTE mode which is basically going back to those giant bitmaps. It's all in the client-side driver for the most part. (I used to be one of the printer driver maintainers for Linux.) It does exist, but it's in custom niches with software written to drive specific hardware.
Windscale wasn't a power reactor, and used horizontal channels with forced air cooling. It's no accident that the later reactors are not air cooled but CO2 cooled and have vertical channels to allow passive convection if the circulation shuts down.
They have, but not at the small scale required. I've tried to find a link for this but can't. When I was chatting to a specialist concrete engineer, he mentioned that some reactors use digital electronics embedded into the reactor walls. Transistor junctions are created from ceramic pieces wrapped/plated with gold, which are then further encased in ceramic and then embedded in the concrete walls. This is mega-electronics rather than micro-electronics, operating at very high voltages, so you can't have that much logic due to the limited space, but for simple but safety critical stuff in high radiation environments this is so large it's not significantly affected by radiation and radiation damage as it is on a small scale.
Where "everything" is a light water reactor such as the BWRs and PWRs of this period, it certainly looks like that's the case. That isn't universally true though; the graphite-moderated Magnox and AGR designs of the same era can passively cool entirely by CO convection. The downside is they have a lower power density, but the only failure I've read about was a partial melt of a single Magnox fuel rod after a blockage in a single channel interrupted the airflow.
A guess: they expect you to click and drag the content? Their focus upon touch is massively detrimental to everyone else.
A runner is a job scheduler running on a remote host, which can be your own machine or hosted wherever you like. When you push a branch or open a merge request etc., you can have it trigger builds on any registered runners (you can have as many as you like). A workspace is a place to store stuff resulting from that build such as libraries, binaries, documentation etc. This means that you can have a CI workflow and deployment hooked directly into the merge request and code review process. This stuff also works at a higher level than github. With github, travis and other CI builds are tied to a project. With gitlab they can also operate at the level of an organisation, so you can use workspaces to test multiple projects in sequence, so that you can do CI and deployment stuff across multiple repositories to test all downstream dependencies or whatever you need to do. It's all documented on the gitlab site. I'm still in the early stages of trying all this stuff out myself.
GitLab does a bunch of stuff which GitHub doesn't. The most significant for me is the integrated CI, and that you can host your own runners and workspaces on your own infrastructure (or some cloud provider). Compared with Travis or some other CI hook on GitHub, this is vastly more flexible and powerful. I also find the ability to assign people for review, milestones and such on issues and merge requests to be very nice features which GitHub lacks. It is a GitHub clone, but they seem to have taken the lead in implementing more advanced functionality. At work, we're currently looking into a trial of GitLab plus our own multi-platform CI runners as an alternative to GitHub+Travis and internal Jenkins with several hundred jobs. It stands to greatly simplify the amount of failures, admin time and developer time keeping that lot going.
Those are just the few I noticed. If you want to use ZFS seriously, FreeBSD gives you a much more useful environment; Linux needs to better integrate it at several levels to bring it up to the same place. Linux sorely needs NFSv4 ACL support in the VFS for starters; it would also make NFSv4 vastly more usable.
It's the past tense, it's perfectly valid and normal English. "I ended; I am ending; I will end".
NFS is still broken for me (Ubuntu 16.10). Fails to mount on startup almost every time; sometimes it succeeds but the chance is about 1 in 10. Some race I guess, but who knows? It's too much of a black box to easily debug. With sysv-rc, I could step through every script by hand, and pinpoint a failure to the line. Contrast that with the "old" FreeBSD and Debian systems using BSD init or sysvinit. They manage to mount the NFS filesystems reliably, every damned time. Which is of course what I'm looking for. Is reliable startup too much to ask for?
There's also another factor to the migration which is familiarity.
Moving from a pre-systemd to a systemd Linux system fundamentally changes many aspects of system administration and maintenance, not just because of the init system replacement, but also from the replacement of all the other tools which systemd absorbed or replaced, or made mandatory. While FreeBSD has its minor differences, a contemporary BSD system is significantly more similar to a pre-systemd Linux system than a systemd Linux system. I personally feel more at home there (it's very similar to a traditional Debian system in many respects), and that my 2+ decades of Unix expertise is as relevant there as it ever has been.
I'm not a Luddite, but change for the sake of change isn't automatically a good thing, and while systemd has some good ideas, the design and implementation of the thing leave a lot to be desired. There doesn't seem to have been as much consideration towards backward compatibility of interfaces and configuration than could have been achieved. Linux was a mature platform, and you don't go around making gratuitous incompatible changes to such systems. At least, not without major fallout, which we continue to see.
This behaviour is where I really dislike the sytemd way. The "it will be done this way, and only this way" attitude. It's my system, why should I not be the one who gets to decide policies such as this? In the initscripts world, this would have been effected through a little configuration file in /etc/default, which would customise the behaviour of the script (or you could edit the script as well if you wanted something truly custom). While systemd does allow some modicum of customisation in the unit files, there's a heck of a lot of policy and behaviour directly encoded in the implementation, which an admin isn't going to be able to touch without rebuilding the thing. While old and crusty, sysv-rc and initscripts left every part out in the open and hence amenable for changing and tweaking. So the "don't boot if a single filesystem in fstab fails to mount" policy would have been a tweak to the mountall script (or better, one of the mount helper shell functions).
Yep, exactly.
I used Linux exclusively from the mid-90s until almost exactly two years back. I was aware of the BSDs, occasionally read about them and once installed it for a few hours just to see, but never had any real reason to bother with them. Seemed like it would be a lot of pain for a worse experience, particularly when you had to build all the ports and cope with worse hardware compatibility.
One of my work colleagues is a long-time Debian user. For the last 18 months, his servers are running OpenBSD.
When it came time to upgrade from wheezy to jessie, I had the option of futzing with the system to retain or reinstall sysvinit, but since it's clearly not supported properly and several key packages deliberately depend upon systemd, you get an inferior experience which is likely to continue to regress. So I looked at FreeBSD, anticipating it would be awful. However, what a revelation. With the new pkg tool, installing and upgrading packages is on a par with apt, and with 25000 packages, it's rare to find anything missing, being at least as comprehensive as the Debian archive. It's also gratifyingly up-to-date for the most part, and if you track the weekly (rather than default quarterly) builds, you're pretty much always up to date with the tools you need (e.g. cmake, clang for me). And then there's ZFS, the "killer feature". Absolutely superb, and really well integrated; vastly easier to use and more featureful than the Linux port. This alone makes it worth using for archiving and serving files.
While there are plenty of people who cope with systemd, or even like it, it's spurred an awful lot of people to step out of the "comfort zone" of Linux, and take a proper look at the alternatives. For some of us, it's been an eye-opener to see just how capable those alternatives are, and we've not looked back.
We previously had these components:
Not only is it modular, the system is fully composable, allowing the admin to build each layer upon each layer to their own liking. The layers are not tightly-coupled, and it's entirely possible to replace any or all of the layers:
When people complain about sysvinit being old and outdated, these claims are usually considering the sysvinit+sysv-rc+initscript triad as a single entity. sysvinit is old, but it's a tool with just two purposes: running specified programs and runlevel switching. You can build anything you want on top of that. It does exactly what it was designed to do, and *only* what it was designed to do. It's not broken, and never was. If you want more functionality, you build that on top of it.
Some parts of the old system were crusty, for example dynamic networking configuration. But the vast majority worked pretty well, and pretty efficiently. And it would have been perfectly possible to fix those issues, with vastly less effort and disruption than throwing it all away and breaking much backward compatibility in the name of inter-distribution uniformity (and consequent stagnation).
Note that while common distributions came with their default, it was absolutely possible to run with all sorts of different combinations of components; Debian supported several. file-rc was a supported alternative to sysv-rc, and daemontools and other alternatives were also available. It's this very flexibility which allowed systemd to be swapped in relatively easily. But consider that once systemd was adopted, the vast majority of this flexibility was lost. The low-level init, the rc runner and the initscripts are all in one place, and it's no longer possible to swap one part for another or tweak one little bit. It's all or nothing, and that will effectively entrench it. As an ex-Debian sysvinit/sysv-rc/initscripts maintainer, I wasn't dictating that you use them all together. You want to use openrc, or daemontools or s6? Go for it, you don't need me to approve it, you do what you like. Want to change the initscripts around to do something different, be my guest. We took care not to break any custom setups on upgrade as well, e.g. preserving file-rc configuration when adding/removing/upgrading packages, as well as helper script API stability. Contrast that with the top-down dictatorial approach which comes from the systemd people: you'll use the system the way we tell you to, and no, we don't approve of you doing anything non-standard unless we like it (and good ideas only come from us, so forget it). And if you do change stuff and it breaks, that's 100% your fault since we don't care to consider this. That's the real difference, the attitude and thought behind the design, and how that affects your freedom to use your system as you see fit. And that's one major reason why my servers now run FreeBSD.
Why would it be desirable to run bash on Windows 10 when I'm going to get a better experience using bash on anything else be that Linux, BSD, either native or virtually. I can understand for some people this might be their only choice, but that doesn't make it good, it's just making the best of a bad situation. If they want me to try it, they'll have to make it better than on Linux, not just "good enough to ship". Because if I'm going to use Windows 10, it had better have some concrete benefit given all its massive downsides.
Agreed. You can enhance an image correctly if that processing only makes use of information in the original image. For example, deconvolution, despeckling, contrast enhancement. These change the image, but the process is either neutral (no information loss) or lossy (some information loss). You can't *add* missing information to an image, because that implies making assumptions about the image which are likely to be incorrect for most cases. Validating such assumptions are correct is extremely difficult. In the case of the google filtering, this is fine if it's purely for aesthetic purposes, but definitely not if it's used for any serious purpose. In the domain I work in (scientific and medical imaging), this would be classed as fraudulent misrepresentation of data, and would get you fired. In fact, a member of my faculty was fired just last week for academic fraud after being discovered to have been misrepresenting their image data over their whole career--it's taken extremely seriously.
sysvinit (or any init) does not need to have a lot of features, so long as you can build more complex features and functionality on top. The very essence of modularity and substitutability. The priority is to be minimal, reliable and bug free. Just look at how many other systems run more advanced stuff on top of sysvinit. It doesn't have to be there in PID1 or provided by the same software package. sysvinit had a very clearly-defined role and within that constrained scope, it provided a working robust solution that worked for multiple decades. The design of sysvinit can be described in a couple of paragraphs of text; you'd need a book to describe systemd, and I doubt even the authors could fully describe it themselves. Overcomplexity and poor design has a cost, and systemd is already an unmaintainable mess.
The very fact that it had a small interface (signals, initctl, inittab) meant that it could very easily be replaced by other systems (and this was done multiple times). The fact that it was easily built upon meant that there were multiple systems built on top of it. It wasn't perfect, and it didn't have every feature everyone wanted. But the point is that it didn't have to while it could be used as a building block by others. systemd is at one extreme (large, complex, tightly-coupled) while s6 is at the other (tiny, simple, loosely-coupled); sysvinit is toward the s6 side of the spectrum; were I writing it from scratch, I'd lean more towards s6 and strip out the more complex bits into separate parts; PID1 doesn't need to deal with inittab for example, nor with runlevels or shutdown.
The core C code of sysvinit was feature-complete, reviewed, debugged and tested years and years ago. Its original design goals were satisfied, and the project is "done". Software does not need continual churn to mark it as "maintained". The same applies to startpar/insserv and other ancillary bits. If you found a bug in sysvinit, I'd review and test it, and push a commit for it. I no longer maintain the Debian packaging, but I still have upstream commit rights should I need them.
Compare this with systemd. It doesn't have the same clearly-defined scope; it's not possible to say when it will be complete as a result. Software can be complete and finished.
When I was a Biology undergraduate in the late '90s I got several haranguing lectures by various researchers about GMOs and how awful it was that people were against them, how safe they were and how they were the experts and knew they were fine. I later checked, and they were funded by Monsanto, Novartis and other big agribusinesses. Being funded to do fundamental research by big companies can introduce bias, and in some cases it's quite unsubtle.
The big problem I have with claiming something is "safe" is that it's often in a very narrowly-defined and short-term scope. In the case of GMOs, that's often limited to "safe for human consumption" ("because we fed it to rodents for a few years with no ill effects" or similar). What about the effects upon people and the environment in the long term (many decades)? Contamination and change to wild populations of the same organism, for example.
The problem I have with it is that it's easy to prove something specific is safe while ignoring the bigger picture. We were assured that glyphosate was safe for bee populations. It had been tested in the lab and we knew its toxicity precisely. But it later turned out that at sublethal doses it screwed up their navigation leaving them unable to make it back to their hives. That hadn't been investigated, and that was an important part of the bigger picture. It wasn't toxic but it was still deadly.
When such important glaring omissions are made, which could potentially destroy our agricultural productivity, leading to starvation and civilisational collapse at the extreme, it also makes you wonder what important but uninvestigated aspects there are in all areas of science. GMOs might be "obviously safe" to the intelligentsia of the present, but who knows if it will be quite so obvious in 30 years time if some fatal flaw is discovered. While it's clearly profitable today, and it might well be safe, it doesn't hurt to have a sensible amount of caution when our entire population is critically dependent upon this stuff for our continued survival.