Don't get me wrong, I was a pretty loud critic. Right now I work on embedded ARM where most COM vendors are still - in 2015 - selling brand new kit which can barely run kernel 3.2, let alone 3.7 required for cgroups/systemd - most systemd fanatics try to tell me to compile from mainline kernel sources, which ignores the fact that these things are all one-of-a-kind once-off type systems where I'd have to port the shitty once-off BSP code which barely made it over the wall in the first place (which I have done - and took weeks on my last attempt, due to shitty quirky b0rked interrupts on the MMC interface for that board), not just "yolo, git pull && recompile dawg # to hell with re-certification and customer revalidation" that web hipsters seem to assume is the case.
But honestly, the technical committee in Debian were the ones we entrusted to make this kind of decision, so it's a meta-lesson in community participation. You can make all the RedHat conspiracies you want but at the end of the day the technical committee volunteers decided it was too much work (read: they didn't have the help like you or I around) to take on spinning a distro with the option to install without systemd.
So all I'm saying is that the Linux ecosystem is shit, but we have only ourselves to blame.
No, you don't have to do it with preseed. Just sudo apt-get install sysvinit-core. At any time, for the entire lifecycle of your installation. You can switch back with sudo apt-get install systemd-sysv at any time too. Change back and forth at will; I have, and whilst I initially had big problems with it, Debian's packaging now even has filled in the gaps that the systemd project themselves seem uninterested in fixing, such as full crypttab support/compatibility that the old sysv/cryptmount ecosystem had supported.
As someone who went to a relatively unknown university (internationally at least), I can also say that the only part of my degree that I simply had to accept with blind faith ("unless you've done maths post-grad, we don't have time to teach why all this is so and how it's derived") was much of two control systems theory subjects. The rest, I could usually derive from first principles. We certainly also studied semiconductors (Si, SiC, GaN - in conjuction with a quantum mechanics subject) such that we could model transistors and other elements from physical fundamentals: exploring different quite complex models and computational approaches, down to simplified formulae, when and which to use for convenience or accuracy.
I get the point you're trying to make, but I'd say most good engineering programmes are throwing up disclaimers in the course material whenver a "recipe" (as opposed to principles) is being taught due to lack of time. Good courses should provide caveats around such things, and make the students understand that they're applying something they don't understand. And hopefully also show what branches of knowledge a "faith item" is derived from so that students can explore on their own if they wish (I hope mose EEs are being taught how to teach themselves and know the limits of their own knowledge). In order to give the physical sciences and mathematics the depth that you would apparently approve of, it would squeeze out so much of the EE domain knowledge and analytical/process/systematics part of the discipline I'm not sure you'd be left with much other than an applied science degree.
I bought my 2009 X61s, a 12" thing, with 8GB RAM. That model was released in 2007. My X230, bought early 2012, has 16GB RAM. I don't know why this 12-13" form factor noadays has gone *backwards* back-to-7-years-ago specs... is it because "UltraBook" has to mean "one DIMM slot"? It's infuriating. Instead of replacing my X230 (the X240 only does 8GB RAM) when the screen broke, I bought parts to repair it. Which was probably for the best anyway (my X230 still does the job), but it's still weird I no longer have any replacement options for this apparently unicorn piece of hardware.
Why do I want 16GB? Because I really enjoy being able to reproduce all my work on this tiny little magical piece of machinery which fits in my backpack with no effort whatsoever. It's the *future*. I shouldn't have to accept mediocrity in the place of something that currently already works. I shouldn't have to stand up more resources at work and VPN in when I already have a working solution. I enjoy being able to work offline; working from flaky 3/4G isn't fun.
To be fair, I do actually do remote debugging in vim with vdebug, but I guess my vim is pretty blinged out. It's no VS of course. And perhaps I'm being ignorant about what it is you actually mean by multiple language support, the toolchains all do this with varying levels of success but I get that managing it can be painful (hence things like pootle).
Virtually my entire career of the last 8 years has been doing productivity software in *nix, so hearing about "THE major [foo]" seems a bit shrill. I did maintain a windows port for something at a previous company, though - Qt wasn't too bad, but again, not as painless as a greenfield app done in.NET would have been but windows wasn't the core business. It's a pity the gnome project has driven any decent devs out of the community, those windows-hating clowns have pretty much doomed Glade's future.
As someone who worked (reluctantly, initially) as a (mostly) Perl dev for nearly 4 years, and has now been doing python for nearly 2 years - I miss lexically scoped variables and the Moose OO system. Here's a comment I made on HN which summarizes my lament regarding pythonistas being unable to fathom the very concept of missing anything from the perl world. TL;DR - Perl+Moose gave me a taste for types and a more declarative programming style which is hard and inefficient to reproduce in python (to be fair, it's inefficient in perl too unles you code mostly immutable objects).
Though I never was aware of him before, I do use debhelper all the time. It's a shame it's come to this. For what it's worth, my impression is that he sees the recent GR proposal two weeks from jessie freeze as being the last straw for him in a long line of suffering from administrative/bureaucratic interference with getting real work done (don't know if he "liked" systemd, but it seems he wants the Debian project to stop wasting energy on debating it endlessly, especially given that endless debates were apparently already had last year).
For me, it's keyscript in crypttab which completely stopped my systems from booting. They're not keen to ever implement becase apparently shell scripts are intrinsically racy (for what it's worth my own keyscripts have a 10s timeout and fall-back to askpass if the crpyt token doesn't become available. I've never had one of my servers reach this time-out, the hardware config rarely ever changes). I wrote about some of the infinite permutations possible to support the use-case of just having a 4-line shell script, but it just seems that systemd is religiously opposed to shell scripts. Eventually, someone pointed out that I could pass keyscript args in the kernel boot parameters which seems to be a partially satisfactory solution for now.
For what it's worth, I do like the declarative nature of systemd for starting processes, socket activation etc. and I have migrated most of my stuff to systemd. It bothers me that debugging dependency issues is still so hard (ever tried "systemd-analyze dot"? the output is completely worthless as a debugging aid). Still, I am uneasy about the dogmatic anti-shellscript religion, I worry about the project's overall approach to security when simply accidentally running systemctl as a non-root user causes it to segfault, and it doesn't seem right that a change in pid1 should even remotely impact userland applications at all, let alone as deeply as systemd has.
At the end of the day, choice of default init system isn't going to make me switch from my favourite distro of the last 14 years (apart from a 2 year excursion to Ubuntu), but I think some of my own hostility toward systemd has been a result of the instantly dismissive remarks whenever I've tried to explain a problem I've had with it - by now I'm realizing that perhaps everybody is just too tired to tell the difference between a valid systemd complaint and yet another "get off my lawn" argument. In any case it's made me realize I should really diversify my tastes a little, currently playing with FreeBSD (again) and NixOS - that has to be a good thing.
I actually can't tell if you're being sarcastic... but you've just described U2F. Whilst YubiKeys and other vendors do challenge/response, I think FIDO usage is typically one-time-pad mode. All other items are addressed (you can set a PIN to protect config and firmware updates, or finalize so it can't be changed ever again).
I eventually got submodules to work properly for me, and have been using them effectively (I think) for a few years now. But it's not easy teaching other devs. Which is why I need to spend some time investigating hg properly. Although you can do sparse checkouts with git, apparently hg has some plugins which allow you to partially clone a repo without necessarily cloning all of the objects in its history (supposedly plugins can fetch that on demand, rather than in the initial clone). It seems this is possible because git is designed around a data format, whereas hg is designed around an API. It all seems great but I just can't find the time to invest in hg
I think he means that it's trivial in Gentoo to run arbitrary versions of any old library or dependency for the sake of a given application that is stuck in the past, not just package-pinning as we do in Debian-land. For example, I have an old gnuradio application that was written for gnuradio 3.6.x, but this was never shipped in any official release of Debian (it went gnuradio 3.5 in wheezy -> gnuradio 3.7 in jessie).
In gentoo it's trivial to have a specific old version of libfoo (and all the old, terribly specific versions of its huge pile of dependencies) installed along-side whatever passes for the current version of libfoo for the rest of your applications which aren't stuck in the past.
In Debian I had to re-build gnuradio from the 3.6 source, with much tweaking of the debian/control, debian/rules files and wading through debian-specific patchsets intended for gnuradio 3.5 or gnuradio 3.7, that don't apply to gnuradio 3.6. And all its dependencies. And suffer the fact that now all of the rest of my applications are forced to use gnuradio 3.6.
Other than being forced to type in 12 passphrases manually to decrypt each hard disk at every single goddamn boot, because custom keyscripts just "aren't the systemd way". Or spending hours figuring out why your Requires=network.target units inexplicably never start on boot, without a single shred of clue or evidence or event in any logs whatsoever, despite LogLevel=Debug and even though network.target clearly flashes by during boot and systemd-analyze clearly shows that it knows about this relationship with your unit and the service starts normally when you login and systemctl start manually. Or that tweaking your daemon args now requires a systemd daemon-reload as well as restart.
Yes, apart from all that, and the time saved now that admins will never have to see another freaky, alien shell script ever again because init systems were the only thing which used them, apart from all that... I'm hoping like hell systemd will hopefully one day buy me something other than more downtime.
For the same reasons your package manager bothers with shasums on the software you install even though the several network layers reaponsible for delivering it already faithfully checksummed each little packet as it flew past: the filesystem is the earliest and only point which knows exactly what files are supposed to actually look like in their entirety. That ZFS/BTRFS scrubs turn up errors on large pools with otherwise perfectly fine hardware means those block/packet level validations are at too low a level to make assurances for the higher level data structures using them.
Docker's transparent caching of RUN/ADD/etc Dockerfile steps has nothing to do with reusable containers. That "it takes less than a second [to] create a handful of [new] containers" is just as true for docker as it is for plain old LXC.
There are two sentences here but I'm not sure how they relate to each other, or the docker feature I'm discussing.
Before docker, as a (not necessarily web) developer I used vagrant to create reproducible environments and build artefacts from a very small set of files. The goal being: I should be able to git clone a very tiny repo tracking a few KiB of scripts and declartiive stuff/config, which - when run - pulls down dependencies, reproduces a build toolchain/environment, performs the build, and delivers substantially identical artefacts regardless of which machine I run it from. I should be able look at an artefact in 2-3 years time, look it up in our version history and reproduce it easily.
Achieving this isn't so easy. Even if I had been using LXC all along I still wouldn't have had the main thing from Dockerfiles that I enjoy: cached build steps. I've been cornered due to time pressures in the past where I can't afford to tweak everything nicely so I've had to release build artefacts from a process which isn't captured in the automation (i.e. I manually babysat the build to meet a requirement on time). This is because hour-long builds make for maybe 3-4 iterations per day, so you have one thread of work where you're hacking interactively while you wait to see if the automation was able to deliver the result you were up to an hour or two ago. I still have this to an extent with Docker (adjust build step and re-run, or step in interactively to explore what's needed) but because Dockerfile steps are cached these iterations are massively accelerated and there's only a handful of occasions where I had to bypass this process now.
I can't speak for using Docker to actually containerize running applications (that's not how I use it), but just this narrow usage of Docker has helped my productivity enormously.
There is *still* no alternative to keyscript in crypttab. Upgrading to systemd trashes a system that relies on smartcards or other hardware to obtain key material for mounting encrypted disks. I wouldn't be this upset, normally - you can imagine that this is just a normal teething problem - except I read through this thread where Lennart seems to doubt the very validity of the entire use-case... I had briefly contemplated seeing if I could contribute to this bug, but the insistence that we should all write C programs (unless you want your initrd to carry python or perl interpreters and all that baggage), for every possible permutation of every key delivery system devisable by admin-kind, made me give up and revert to sysvinit instead.
I believe Advantech will still happily sell you ISA backplanes. At the same time I put these things together, I had to reverse-engineer and fabricate some old I/O cards which had "unique" (incompatible with readily available cards) interrupt register mappings, also with EAGLE - great software!
I should mention: the MS-DOS system has outlasted three replacement attempts (two windows-based applications were from the original vendor who sold the MS-DOS system). There's just something completely unbreakable about the old stuff.
Many industrial computers have CF-card slots for this very application. I put together a few MS-DOS systems using SanDisk CF cards around 8 years ago and they're still going strong, using a variant of one of these cards which has a CF slot built-in (so no need for a CF -> IDE adapter): PCA-6751
That's true. People scoff at the older taxonomic groupings from before we had molecular evidence, but actually I'm often surprised at how similar new phylogenies are to huge chunks of the old taxonomies. What's more, at least with plants, one molecular study can produce quite a different looking evolutionary tree to another depending on what genes they used to compute them.
Which begs the quesiton... what's the ground truth? Data from classical taxonomy is actually extremely valuable. It can help inform molecular studies. It can be used to feed consensus trees or indicate which genes might yield certain phenotypes.
There seems to be many who think that with enough CPU power and algorithms we can turn any old meaningless garbage string of GATC into something we can pretend is useful. It seems like a lossy way of thinking... you can do interesting work without names, that's true - but the reckless abandon and total lack of scientific discipline when using names would never be tolerated in the "harder" sciences.
I dare you to pick up ten different papers using species or group names... and find even just one that cites the name in a reporducible, scientifically useful way (i.e. cites the taxnomic publication which specifies what they mean when they use the name).
I wouldn't ask Chrome to do anything more than it already does, which is to just do its job - help me navigate the web. I refuse to believe that a prominent domain part which yields the exact same phishing mitigation, and a visible path part are mutually exclusive things.
I am at a loss as to why you'd dismiss the ability to spot obviously funky URLs with a dodgy "but script injection vulnerabilities are browser-independent!" straw man; surely there's a stronger rebuttable to my thoughts than this.
Are you seriously suggesting that a prominent domain part and a visible path part are mutually exclusive?
And whilst it's fun to talk about redundancy between the <h1> text, title text and the address bar, it's also true that the address bar is the only one that's always visible in a consistent location that isn't lying to you.
There's obvious ways to shoot for the phishing mitigations that this is apparently seeking to achieve, without turning the web into an app store. We used to make fun of stupid flash sites due to lack of linkability, is it really necessary to so thoroughly lunge off the cliff into this idiocy now?
I wonder how many bad guys are already thinking of ways to exploit this. Yes the domain is more prominent, that should have been fixed years ago - but how many sites out there are completely free of XSS vulnerabilites? When this eventually becomes non-optional, how am I going to spot https://mybank.foo/?q="><script>evil; stuff;</script>
?
The perfect irony of course is that Google's own pagerank depends on cross-site linking... By robbing people of URLs, a future generation of net users will grow up never knowing how to share a page with their friends unless there's a sharing mechanism within the same site their friends already use.
Slashdot Mirror
I'm working ~80% in python now. I miss Moose. A lot. That, and lexical scoping.
Don't get me wrong, I was a pretty loud critic. Right now I work on embedded ARM where most COM vendors are still - in 2015 - selling brand new kit which can barely run kernel 3.2, let alone 3.7 required for cgroups/systemd - most systemd fanatics try to tell me to compile from mainline kernel sources, which ignores the fact that these things are all one-of-a-kind once-off type systems where I'd have to port the shitty once-off BSP code which barely made it over the wall in the first place (which I have done - and took weeks on my last attempt, due to shitty quirky b0rked interrupts on the MMC interface for that board), not just "yolo, git pull && recompile dawg # to hell with re-certification and customer revalidation" that web hipsters seem to assume is the case.
But honestly, the technical committee in Debian were the ones we entrusted to make this kind of decision, so it's a meta-lesson in community participation. You can make all the RedHat conspiracies you want but at the end of the day the technical committee volunteers decided it was too much work (read: they didn't have the help like you or I around) to take on spinning a distro with the option to install without systemd.
So all I'm saying is that the Linux ecosystem is shit, but we have only ourselves to blame.
No, you don't have to do it with preseed. Just sudo apt-get install sysvinit-core. At any time, for the entire lifecycle of your installation. You can switch back with sudo apt-get install systemd-sysv at any time too. Change back and forth at will; I have, and whilst I initially had big problems with it, Debian's packaging now even has filled in the gaps that the systemd project themselves seem uninterested in fixing, such as full crypttab support/compatibility that the old sysv/cryptmount ecosystem had supported.
As someone who went to a relatively unknown university (internationally at least), I can also say that the only part of my degree that I simply had to accept with blind faith ("unless you've done maths post-grad, we don't have time to teach why all this is so and how it's derived") was much of two control systems theory subjects. The rest, I could usually derive from first principles. We certainly also studied semiconductors (Si, SiC, GaN - in conjuction with a quantum mechanics subject) such that we could model transistors and other elements from physical fundamentals: exploring different quite complex models and computational approaches, down to simplified formulae, when and which to use for convenience or accuracy.
I get the point you're trying to make, but I'd say most good engineering programmes are throwing up disclaimers in the course material whenver a "recipe" (as opposed to principles) is being taught due to lack of time. Good courses should provide caveats around such things, and make the students understand that they're applying something they don't understand. And hopefully also show what branches of knowledge a "faith item" is derived from so that students can explore on their own if they wish (I hope mose EEs are being taught how to teach themselves and know the limits of their own knowledge). In order to give the physical sciences and mathematics the depth that you would apparently approve of, it would squeeze out so much of the EE domain knowledge and analytical/process/systematics part of the discipline I'm not sure you'd be left with much other than an applied science degree.
I bought my 2009 X61s, a 12" thing, with 8GB RAM. That model was released in 2007. My X230, bought early 2012, has 16GB RAM. I don't know why this 12-13" form factor noadays has gone *backwards* back-to-7-years-ago specs... is it because "UltraBook" has to mean "one DIMM slot"? It's infuriating. Instead of replacing my X230 (the X240 only does 8GB RAM) when the screen broke, I bought parts to repair it. Which was probably for the best anyway (my X230 still does the job), but it's still weird I no longer have any replacement options for this apparently unicorn piece of hardware.
Why do I want 16GB? Because I really enjoy being able to reproduce all my work on this tiny little magical piece of machinery which fits in my backpack with no effort whatsoever. It's the *future*. I shouldn't have to accept mediocrity in the place of something that currently already works. I shouldn't have to stand up more resources at work and VPN in when I already have a working solution. I enjoy being able to work offline; working from flaky 3/4G isn't fun.
To be fair, I do actually do remote debugging in vim with vdebug, but I guess my vim is pretty blinged out. It's no VS of course. And perhaps I'm being ignorant about what it is you actually mean by multiple language support, the toolchains all do this with varying levels of success but I get that managing it can be painful (hence things like pootle).
Virtually my entire career of the last 8 years has been doing productivity software in *nix, so hearing about "THE major [foo]" seems a bit shrill. I did maintain a windows port for something at a previous company, though - Qt wasn't too bad, but again, not as painless as a greenfield app done in .NET would have been but windows wasn't the core business. It's a pity the gnome project has driven any decent devs out of the community, those windows-hating clowns have pretty much doomed Glade's future.
As someone who worked (reluctantly, initially) as a (mostly) Perl dev for nearly 4 years, and has now been doing python for nearly 2 years - I miss lexically scoped variables and the Moose OO system. Here's a comment I made on HN which summarizes my lament regarding pythonistas being unable to fathom the very concept of missing anything from the perl world. TL;DR - Perl+Moose gave me a taste for types and a more declarative programming style which is hard and inefficient to reproduce in python (to be fair, it's inefficient in perl too unles you code mostly immutable objects).
Though I never was aware of him before, I do use debhelper all the time. It's a shame it's come to this. For what it's worth, my impression is that he sees the recent GR proposal two weeks from jessie freeze as being the last straw for him in a long line of suffering from administrative/bureaucratic interference with getting real work done (don't know if he "liked" systemd, but it seems he wants the Debian project to stop wasting energy on debating it endlessly, especially given that endless debates were apparently already had last year).
For me, it's keyscript in crypttab which completely stopped my systems from booting. They're not keen to ever implement becase apparently shell scripts are intrinsically racy (for what it's worth my own keyscripts have a 10s timeout and fall-back to askpass if the crpyt token doesn't become available. I've never had one of my servers reach this time-out, the hardware config rarely ever changes). I wrote about some of the infinite permutations possible to support the use-case of just having a 4-line shell script, but it just seems that systemd is religiously opposed to shell scripts. Eventually, someone pointed out that I could pass keyscript args in the kernel boot parameters which seems to be a partially satisfactory solution for now.
For what it's worth, I do like the declarative nature of systemd for starting processes, socket activation etc. and I have migrated most of my stuff to systemd. It bothers me that debugging dependency issues is still so hard (ever tried "systemd-analyze dot"? the output is completely worthless as a debugging aid). Still, I am uneasy about the dogmatic anti-shellscript religion, I worry about the project's overall approach to security when simply accidentally running systemctl as a non-root user causes it to segfault, and it doesn't seem right that a change in pid1 should even remotely impact userland applications at all, let alone as deeply as systemd has.
At the end of the day, choice of default init system isn't going to make me switch from my favourite distro of the last 14 years (apart from a 2 year excursion to Ubuntu), but I think some of my own hostility toward systemd has been a result of the instantly dismissive remarks whenever I've tried to explain a problem I've had with it - by now I'm realizing that perhaps everybody is just too tired to tell the difference between a valid systemd complaint and yet another "get off my lawn" argument. In any case it's made me realize I should really diversify my tastes a little, currently playing with FreeBSD (again) and NixOS - that has to be a good thing.
I actually can't tell if you're being sarcastic... but you've just described U2F. Whilst YubiKeys and other vendors do challenge/response, I think FIDO usage is typically one-time-pad mode. All other items are addressed (you can set a PIN to protect config and firmware updates, or finalize so it can't be changed ever again).
I eventually got submodules to work properly for me, and have been using them effectively (I think) for a few years now. But it's not easy teaching other devs. Which is why I need to spend some time investigating hg properly. Although you can do sparse checkouts with git, apparently hg has some plugins which allow you to partially clone a repo without necessarily cloning all of the objects in its history (supposedly plugins can fetch that on demand, rather than in the initial clone). It seems this is possible because git is designed around a data format, whereas hg is designed around an API. It all seems great but I just can't find the time to invest in hg
I think he means that it's trivial in Gentoo to run arbitrary versions of any old library or dependency for the sake of a given application that is stuck in the past, not just package-pinning as we do in Debian-land. For example, I have an old gnuradio application that was written for gnuradio 3.6.x, but this was never shipped in any official release of Debian (it went gnuradio 3.5 in wheezy -> gnuradio 3.7 in jessie).
In gentoo it's trivial to have a specific old version of libfoo (and all the old, terribly specific versions of its huge pile of dependencies) installed along-side whatever passes for the current version of libfoo for the rest of your applications which aren't stuck in the past.
In Debian I had to re-build gnuradio from the 3.6 source, with much tweaking of the debian/control, debian/rules files and wading through debian-specific patchsets intended for gnuradio 3.5 or gnuradio 3.7, that don't apply to gnuradio 3.6. And all its dependencies. And suffer the fact that now all of the rest of my applications are forced to use gnuradio 3.6.
Oh, how embarassing.... the above post wasn't intended for you.
Other than being forced to type in 12 passphrases manually to decrypt each hard disk at every single goddamn boot, because custom keyscripts just "aren't the systemd way". Or spending hours figuring out why your Requires=network.target units inexplicably never start on boot, without a single shred of clue or evidence or event in any logs whatsoever, despite LogLevel=Debug and even though network.target clearly flashes by during boot and systemd-analyze clearly shows that it knows about this relationship with your unit and the service starts normally when you login and systemctl start manually. Or that tweaking your daemon args now requires a systemd daemon-reload as well as restart.
Yes, apart from all that, and the time saved now that admins will never have to see another freaky, alien shell script ever again because init systems were the only thing which used them, apart from all that... I'm hoping like hell systemd will hopefully one day buy me something other than more downtime.
For the same reasons your package manager bothers with shasums on the software you install even though the several network layers reaponsible for delivering it already faithfully checksummed each little packet as it flew past: the filesystem is the earliest and only point which knows exactly what files are supposed to actually look like in their entirety. That ZFS/BTRFS scrubs turn up errors on large pools with otherwise perfectly fine hardware means those block/packet level validations are at too low a level to make assurances for the higher level data structures using them.
Docker's transparent caching of RUN/ADD/etc Dockerfile steps has nothing to do with reusable containers. That "it takes less than a second [to] create a handful of [new] containers" is just as true for docker as it is for plain old LXC.
There are two sentences here but I'm not sure how they relate to each other, or the docker feature I'm discussing.
Before docker, as a (not necessarily web) developer I used vagrant to create reproducible environments and build artefacts from a very small set of files. The goal being: I should be able to git clone a very tiny repo tracking a few KiB of scripts and declartiive stuff/config, which - when run - pulls down dependencies, reproduces a build toolchain/environment, performs the build, and delivers substantially identical artefacts regardless of which machine I run it from. I should be able look at an artefact in 2-3 years time, look it up in our version history and reproduce it easily.
Achieving this isn't so easy. Even if I had been using LXC all along I still wouldn't have had the main thing from Dockerfiles that I enjoy: cached build steps. I've been cornered due to time pressures in the past where I can't afford to tweak everything nicely so I've had to release build artefacts from a process which isn't captured in the automation (i.e. I manually babysat the build to meet a requirement on time). This is because hour-long builds make for maybe 3-4 iterations per day, so you have one thread of work where you're hacking interactively while you wait to see if the automation was able to deliver the result you were up to an hour or two ago. I still have this to an extent with Docker (adjust build step and re-run, or step in interactively to explore what's needed) but because Dockerfile steps are cached these iterations are massively accelerated and there's only a handful of occasions where I had to bypass this process now.
I can't speak for using Docker to actually containerize running applications (that's not how I use it), but just this narrow usage of Docker has helped my productivity enormously.
There is *still* no alternative to keyscript in crypttab. Upgrading to systemd trashes a system that relies on smartcards or other hardware to obtain key material for mounting encrypted disks. I wouldn't be this upset, normally - you can imagine that this is just a normal teething problem - except I read through this thread where Lennart seems to doubt the very validity of the entire use-case... I had briefly contemplated seeing if I could contribute to this bug, but the insistence that we should all write C programs (unless you want your initrd to carry python or perl interpreters and all that baggage), for every possible permutation of every key delivery system devisable by admin-kind, made me give up and revert to sysvinit instead.
I believe Advantech will still happily sell you ISA backplanes. At the same time I put these things together, I had to reverse-engineer and fabricate some old I/O cards which had "unique" (incompatible with readily available cards) interrupt register mappings, also with EAGLE - great software!
I should mention: the MS-DOS system has outlasted three replacement attempts (two windows-based applications were from the original vendor who sold the MS-DOS system). There's just something completely unbreakable about the old stuff.
Many industrial computers have CF-card slots for this very application. I put together a few MS-DOS systems using SanDisk CF cards around 8 years ago and they're still going strong, using a variant of one of these cards which has a CF slot built-in (so no need for a CF -> IDE adapter): PCA-6751
Yes, that's a problem. BHL is really the go-to source for plant people I've worked with in the past.
That's true. People scoff at the older taxonomic groupings from before we had molecular evidence, but actually I'm often surprised at how similar new phylogenies are to huge chunks of the old taxonomies. What's more, at least with plants, one molecular study can produce quite a different looking evolutionary tree to another depending on what genes they used to compute them.
Which begs the quesiton... what's the ground truth? Data from classical taxonomy is actually extremely valuable. It can help inform molecular studies. It can be used to feed consensus trees or indicate which genes might yield certain phenotypes.
There seems to be many who think that with enough CPU power and algorithms we can turn any old meaningless garbage string of GATC into something we can pretend is useful. It seems like a lossy way of thinking... you can do interesting work without names, that's true - but the reckless abandon and total lack of scientific discipline when using names would never be tolerated in the "harder" sciences.
I dare you to pick up ten different papers using species or group names... and find even just one that cites the name in a reporducible, scientifically useful way (i.e. cites the taxnomic publication which specifies what they mean when they use the name).
I wouldn't ask Chrome to do anything more than it already does, which is to just do its job - help me navigate the web. I refuse to believe that a prominent domain part which yields the exact same phishing mitigation, and a visible path part are mutually exclusive things.
I am at a loss as to why you'd dismiss the ability to spot obviously funky URLs with a dodgy "but script injection vulnerabilities are browser-independent!" straw man; surely there's a stronger rebuttable to my thoughts than this.
Are you seriously suggesting that a prominent domain part and a visible path part are mutually exclusive?
And whilst it's fun to talk about redundancy between the <h1> text, title text and the address bar, it's also true that the address bar is the only one that's always visible in a consistent location that isn't lying to you.
There's obvious ways to shoot for the phishing mitigations that this is apparently seeking to achieve, without turning the web into an app store. We used to make fun of stupid flash sites due to lack of linkability, is it really necessary to so thoroughly lunge off the cliff into this idiocy now?
I wonder how many bad guys are already thinking of ways to exploit this. Yes the domain is more prominent, that should have been fixed years ago - but how many sites out there are completely free of XSS vulnerabilites? When this eventually becomes non-optional, how am I going to spot https://mybank.foo/?q="><script>evil; stuff;</script>
?
The perfect irony of course is that Google's own pagerank depends on cross-site linking... By robbing people of URLs, a future generation of net users will grow up never knowing how to share a page with their friends unless there's a sharing mechanism within the same site their friends already use.