Follow Slashdot stories on Twitter


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Thank you Debian maintainers (Score 1) 118

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?

Comment Re:One can hope (Score 1) 118

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.

Comment Re:One can hope (Score 4, Interesting) 118

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).

Comment Re:One can hope (Score 1) 118

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.

Comment Re:One can hope (Score 4, Informative) 118

Yes, we did have that modularity.

We previously had these components:
  • 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.

Comment What's better (Score 1) 403

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.

Comment Re:Depends on enhancement (Score 2) 79

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.

Comment Re:RTFA, please. (Score 2) 508

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.

Comment Re:RTFA, please. (Score 3, Informative) 508

"Unchanging" does not mean "unmaintained".

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.

Comment Re:GMOs (Score 1) 527

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.

Comment Re:What happended to slashdot? (Score 2) 86

There's a difference between "hating change" and being uninterested in over-hyped junk with no practical relevance. And yes, I've been to a demo of the HoloLens and seen it in real life. It was crap and even the rabid fanatic doing the demo couldn't make it work properly during his demo. That's Microsoft software again! Make one that actually works well, as well as actually solving problems I have, and I might start to get interested. But right now, it's nothing more than a toy trying desperately to provide solutions to problems which people don't have. It lacks purpose, in addition to being a mediocre implementation of the concept. Having been reading slashdot for nearly 20 years now, I think it's certainly fair to say I've become less susceptible to hype. Lots of stuff has been hyped over the years and come to nothing. Most of it was crap. I don't hate change, I just don't have interest in over-hyped useless crap anymore. Let it establish itself, and then I might get interested if there's worth in it. I'll leave the rabid fanaticism to others.

Comment Re:Did it occur to them that no one wants them? (Score 1) 86

Yep, went to a talk/demo three weeks back. Looked interesting and promising, but in reality I was completely underwhelmed. Didn't help that the speaker was a rabid Microsoft fanatic and spent most of the talk going on about how awesome Microsoft were rather than talking about the technology, but the technology itself is nothing particularly special. And most of the usage scenarios and games they had for it were contrived and useless. They also chose to go with an Intel Atom processor in the unit rather than a less power hungry ARM. I really don't need a hot CPU plastered onto my forehead. The power consumption was so bad the guy had a big USB battery pack in the back of his pants! The overall idea does have some merit. The implementation is respectable but frighteningly expensive and not that impressive overall. I don't think the HoloLens will take off, but the concept might once it is refined somewhat. Given that you can almost do what it does today with a mobile phone in a harness and a front-facing camera, I suspect that other manufacturers will be able to make a better product for a fraction of the price.

Comment Re:Did it occur to them that no one wants them? (Score 1) 86

Actually, they didn't get over it, at least in some cases. I can't play a lot of the early 3D games. They make me want to vomit and induce violent headaches with only a few tens of minutes of use. Most newer games don't. And I think it's largely due to differences in the FOV and camera positioning. The original Star Wars: Jedi Knight/Dark Forces were almost unplayable for me, as were a lot of others in this era. I stuck them out and suffered, but only in small doses. JKII/III, Mass Effect, and post recent/current games are totally OK (but not all). A lot of this might be down to my eyes and physiology, but it's also absolutely the case that the individual games are prone to causing this, and those old games were especially bad for it (for me, and I suspect others).

Comment Re: Que the consultant guy... (Score 3, Informative) 162

You've posted this exact text to other stories. Please stop. The content is garbage. Code compiled with GCC is not forced to be GPL and never has been. Your compiled code retains your licence. Changes you make to the Linux kernel would be required to be GPL if you distribute them, the GPL being a *distribution* licence, but are required to be given to people you *distribute* the changes to only, not the whole world. If this is for real, and not just a lame troll, you got lousy advice from your "lawyers".

Comment Unicode (Score 1) 200

Maybe the Unicode consortium need to supplement the ZWJ character with an SJW character.

In all seriousness, while Unicode is intended to be universal, I don't think that bullshit emojis have a place in it. We have markup in addition to characters, not to mention SVG and other formats which can better represent them. They don't have to be in the Unicode standard.

Slashdot Top Deals

Support bacteria -- it's the only culture some people have!