It isn't sexism if it's the actual truth, and validated by our current scientific understanding. Being controversial and unpalatable doesn't make it incorrect.
It is not "clearly" saying that at all. Not taking up a stressful job does not imply that you are incapable of doing the job and handling the stress, but rather that you make a choice to do something else instead. Avoidance does not imply incapability.
They are superficially similar but are actually different. They have different kinetics, absorption rates, and may be processed via different pathways (complex carbohydrates may require breakdown by gut flora into other forms) and in different organs (fructose and other sugars require conversion to other forms in the liver). Eating a spoonful of sucrose is very different than eating a spoonful of rice, potato or pasta.
The caveat, AFAICR, is that the binary builds don't have security updates, being built at the time of release, so you have to build from source if you care about security updates. It's been a topic of conversation on the openbsd list a few times.
As of today, there are 26816 ports. It's up there with Debian in terms of the quantity of source packages and has contained pretty much everything I use in a Debian/Ubuntu installation.
While this post was marked "5, Funny" I personally feel it's more of a tragedy that Linux has been trashed so thoroughly by such a small group of people. If you'd suggested to me a few years back that in 2017 I'd be using FreeBSD and no longer a Debian developer I wouldn't have believed you, and yet that's where I've ended up.
What useradd does or does not do is an irrelevance; there are many tools to create user accounts. Many of us deal with large LDAP/AD setups where the usernames don't even get created by Linux tools. So long as getpwnam[_r] return nonzero, that username is valid from the point of view of the system.
Username validation is way, way outside systemd's remit.
FWIW, FreeBSD 11.1 has a current clang (4.0.0) which supports C++17 and earlier. 11.0 had 3.8.0 supporting C++14 and 10.x had 3.4.x supporting C++11. All of these have been significantly nicer to develop with than CentOS 6 or 7 (even with EPEL).
Yes, there are workarounds like devtoolset, but they come with their own caveats including incompatibility with the base platform.
I have no problem with the intent of LTS releases, so long as you don't want to use them to deploy *new* code. Requiring new code to work with old LTS releases holds back development due to the LTS releases inevitably being the lowest comnon denominator which can push the use of contemporary features a decade into the future, and I find that a decidedly negative consequence..
I find the CentOS releases get way too stale. CentOS 6 is really crusty at this point. And even CentOS 7 is getting old now; its GCC is missing C++14 features I need.
Look, NFS mounting is broken. BROKEN. It works a small percentage of the time, but most of the time it fails to mount anything successfully at boot. The mount exists, but any attempt to use the mount results in an IO error. systemd fundamentally failed to bring up the NFS services properly, leading to a non-functional system. I can log in on the console, unmount everything, then remount it and it works perfectly after that manual fix. But on a day to day basis, I can't rely on using NFS mounts with systemd.
This is unbelievable. Correct order of service startup was one of the big arguments for systemd. Despite the fact that this was never a problem with insserv dependency ordering with sysv-rc. My FreeBSD systems can mount NFS correctly. Every. Single. Time. Because their startup isn't buggy or defective. systemd has had this issue with NFS for bloody years. Still unfixed today. Don't make excuses for it; fix it.
Startup should be deterministic and consistent. With systemd, it's a lottery whether the system will come up correctly configured or not. That's plain stupid, and a massive regression. I've also had other instances where the boot hangs indefinitely; this is also beyond ridicule.
Agreed, training is definitely a key part! At least where I used to work, because the two systems ran in parallel everyone was trained daily; any service outage would be a non-event other than having to do some data entry once the outage was fixed. For systems where you explicitly switch then training for that disruption is going to be even more important.
Businesses can and do have contingency plans to work without computers. It's absolutely possible with a little foresight and planning.
I used to work in an industrial complex which was highly automated. But for every bit of process, there was an accompanying card with all the details filled out in ink. The card would be physically passed around the plant to hand over responsibility and document every part of the process. For each place the card passed through, local log books would record every addition to the card, and they details would also be entered into the computer. You might think this redundant, but it provided three important things: (1) audit - we could check that the computer details matched the card and that the local logs matched the card and the computer, to trace any discrepancies in the case of entry errors (2) physical accountability and traceability and (3) the ability to run the entire plant without any network connectivity; the details of the processes could be entered retrospectively.
An airline can certainly mitigate a lot of what went wrong. Physically print out the passenger lists to permit check in and boarding. Most people book the flights well in advance; you can cope with most passengers with ease, even moving them between flights, if you have a backup paper system in place. Physically cross them off with the date and time you did it, then add them to a list that the gate staff can use. Card payment isn't an issue--most people already paid in advance; for those that didn't you can probably take the payment, physically document it and enter it into the system at a later time. It's absolutely doable, and any company who cares about surviving should have a system in place.
The plant I worked at did this for legal and financial reasons. If a computer outage costs millions of pounds an hour, then you make sure it's covered. BA's outage likely cost much more than that.
The effect might not be immediate. It might not be noticeable or detectable for a few years, at which point it might be too late. Ecosystems are very complex, and can be fragile in ways we don't even suspect when some critical but unappreciated part is disrupted. When it concerns our future food production, it's only right to be concerned about it, irrespective of whether it eventually turns out to be a serious problem or not.
It really depends on what your priorities are. My current system is an FX-8350, and the new stuff does look like a really nice upgrade. It's definitely faster, and definitely more power efficient. But I do need to factor the cost of a new mainboard, CPU, RAM against keeping what I have. I'll pay more for the ongoing running cost in electricity usage for sure, but that usage is dwarfed by the replacement cost of all that hardware--it will take many years to break even. So I'll probably hold off for a year or so, and the cost of all the parts will be even cheaper by that point.
I'd be in more of a rush to upgrade if what I had was noticeably bad, but the 8350 is a fine processor for everything I do, from gaming to compiling and running multi-threaded analysis code. While the new stuff would be nice for all these things, it's not sufficiently compelling to replace the hardware today.
Concorde used reheat only during take-off and then accelerating through the sound barrier. It definitely didn't use it for supercruise at Mach 2.2; at this speed the Olympus engines operated at their maximum efficiency--as designed.
Kung Fury review and movie. If a single person with a small budget from Kickstarter can do that, then Hollywood should be orders of magnitude better. As it is, I found this more entertaining than the latest Iron Man or other Marvel stuff. I may just have questionable taste, but while this is a cheap and cheesy feature, it also quite clever--the whole thing is a parody of movie tropes, doesn't take itself seriously, and ticks a large number of boxes.
Exactly. If you're ethical, you won't leave any access possible, so there's no doubt as to your integrity.
When I left my previous employer, a small business where I had full admin rights (I set most of it up), I made sure to wipe all my ssh keys, lock and delete my accounts so that the company directors could be sure I no longer had any access, remote or otherwise. No cron jobs, no source code, no customer information. A few months later they asked me if I could look into a problem that cropped up, and had to tell them it was impossible since I had no means to log in, but I could visit in person to briefly talk to their new staff. Mutual respect, and no possibility of any suspect practices due to being completely transparent about the leaving process. It's idiots like in TFA that give all of us a bad reputation, or at least cast a shadow of doubt upon our professionalism. Unfortunately, it's all too easy to do that if you don't want to act in good faith, particularly when you are entrusted with privileged access to a companies systems and processes.
Some electronic music, e.g. some trance, can be beautiful and subtle. But the best artists are often classically trained musicians, who can actually compose and arrange music. Both trance and classical music have very similar structure, so it makes sense that one can translate well to the other. For example, you can listen to some of Above & Beyond's early work like Tri-State, Sirens of the Sea performed by an orchestra; would have likely been better had it been written for an orchestra in the first place, but it showed that the various electronic instruments, effects etc. did almost directly translate to a classical setting. That said, there's an awful lot of crap out there, and being able to use a sequencer doesn't make you a gifted composer. I watched a youtube video of a trance producer last week going into how to use Ableton, and while interesting the result was terrible, almost as you say at pots and pans level.
I've read the pages where Microsoft attempt to justify this decision, e.g. https://blogs.msdn.microsoft.c.... I don't buy it. It's institutional laziness and resistance to change first and foremost. Choosing on a per-application basis whether to make it 32-bit or 64-bit is madness, especially in the situation here where you force every plugin and library being loaded to be 32-bit. You're developing a *system*, but it's really an agglomeration of different bits with little coherence or common direction.
Linux distributions got this right. The whole installation is x86 or amd64. No confused mess of the two, x86 compat libs aside. We didn't agonise over minutiae, we did a complete conversion by treating them as two separate architctures, with biarch and multiarch for running legacy code. As is typical for Microsoft, they didn't have a transition plan, leaving much of their product line 32-bit only despite most developers and user having fully transitioned to x64 Windows over a decade or more back. Meanwhile on FreeBSD, Linux and MacOS X 32-bit is a distant memory on 64-bit platforms; the transition was done well over a decade back for many distributions as amd64 rebuilds were completed. What's tragic is they did the exact same thing with the 32-bit transition. Remember what a mess it was in the mid-90s to mid 2000s with a jumble of 16- and 32-bit code? It's exactly the same mess today with 32-bit and 64-bit code! They need some direction from the top to pull their fingers out and go 64-bit only, or do builds of both. If the BSD and Linux distros can build code for >10 architectures then I'm sure Microsoft can manage two, or three if we count their arm port (which is even more limited due to their x86 depenence, who would have expected that... Maybe build all your code on all architectures and x64 and arm could be first-class citizens.)
The device error correction is probabilistic. It won't necessarily know the data is "bad". And there can be firmware bugs which make it return or store bad data. What about phantom reads and writes.
https://www.youtube.com/watch?... is a very interesting presentation from Bryan Cantrill about all sorts of bitrot and storage stuff.
When it comes to archival, ZFS is a production quality filesystem and volume manager intended for serious use. Btrfs is perpetually pre-alpha. Using it for archival would be foolish. It's also tied to a single implementation on a single operating system. I can (and have) run "zpool export" on a Linux server, removed the disks and slotted them into a FreeBSD server, then run "zpool import": data immediately on-line and mounted. It would also have worked for any other OS implementing ZFS; for data transportability it's the most feature cross-platform filesystem right now, given that the alternatives are crude filesystems like FAT. Archival implies the ability to read the data in a few decades, and I would bet that ZFS outlasts Btrfs by a significant margin. The single implementation of Btrfs might have been removed or changed incompatibly before you need to reread your data, and that presupposing that Btrfs wouldn't trash your data unrecoverably in the interim; after several total dataloss incidents with Btrfs due to implementation bugs in Btrfs, let's just say I'm a bit more grounded and objective as to its true merits.
Slashdot Mirror
It isn't sexism if it's the actual truth, and validated by our current scientific understanding. Being controversial and unpalatable doesn't make it incorrect.
It is not "clearly" saying that at all. Not taking up a stressful job does not imply that you are incapable of doing the job and handling the stress, but rather that you make a choice to do something else instead. Avoidance does not imply incapability.
They are superficially similar but are actually different. They have different kinetics, absorption rates, and may be processed via different pathways (complex carbohydrates may require breakdown by gut flora into other forms) and in different organs (fructose and other sugars require conversion to other forms in the liver). Eating a spoonful of sucrose is very different than eating a spoonful of rice, potato or pasta.
The caveat, AFAICR, is that the binary builds don't have security updates, being built at the time of release, so you have to build from source if you care about security updates. It's been a topic of conversation on the openbsd list a few times.
As of today, there are 26816 ports. It's up there with Debian in terms of the quantity of source packages and has contained pretty much everything I use in a Debian/Ubuntu installation.
While this post was marked "5, Funny" I personally feel it's more of a tragedy that Linux has been trashed so thoroughly by such a small group of people. If you'd suggested to me a few years back that in 2017 I'd be using FreeBSD and no longer a Debian developer I wouldn't have believed you, and yet that's where I've ended up.
Username validation is way, way outside systemd's remit.
FWIW, FreeBSD 11.1 has a current clang (4.0.0) which supports C++17 and earlier. 11.0 had 3.8.0 supporting C++14 and 10.x had 3.4.x supporting C++11. All of these have been significantly nicer to develop with than CentOS 6 or 7 (even with EPEL).
Yes, there are workarounds like devtoolset, but they come with their own caveats including incompatibility with the base platform. I have no problem with the intent of LTS releases, so long as you don't want to use them to deploy *new* code. Requiring new code to work with old LTS releases holds back development due to the LTS releases inevitably being the lowest comnon denominator which can push the use of contemporary features a decade into the future, and I find that a decidedly negative consequence..
I find the CentOS releases get way too stale. CentOS 6 is really crusty at this point. And even CentOS 7 is getting old now; its GCC is missing C++14 features I need.
This is unbelievable. Correct order of service startup was one of the big arguments for systemd. Despite the fact that this was never a problem with insserv dependency ordering with sysv-rc. My FreeBSD systems can mount NFS correctly. Every. Single. Time. Because their startup isn't buggy or defective. systemd has had this issue with NFS for bloody years. Still unfixed today. Don't make excuses for it; fix it.
Startup should be deterministic and consistent. With systemd, it's a lottery whether the system will come up correctly configured or not. That's plain stupid, and a massive regression. I've also had other instances where the boot hangs indefinitely; this is also beyond ridicule.
Agreed, training is definitely a key part! At least where I used to work, because the two systems ran in parallel everyone was trained daily; any service outage would be a non-event other than having to do some data entry once the outage was fixed. For systems where you explicitly switch then training for that disruption is going to be even more important.
Businesses can and do have contingency plans to work without computers. It's absolutely possible with a little foresight and planning. I used to work in an industrial complex which was highly automated. But for every bit of process, there was an accompanying card with all the details filled out in ink. The card would be physically passed around the plant to hand over responsibility and document every part of the process. For each place the card passed through, local log books would record every addition to the card, and they details would also be entered into the computer. You might think this redundant, but it provided three important things: (1) audit - we could check that the computer details matched the card and that the local logs matched the card and the computer, to trace any discrepancies in the case of entry errors (2) physical accountability and traceability and (3) the ability to run the entire plant without any network connectivity; the details of the processes could be entered retrospectively. An airline can certainly mitigate a lot of what went wrong. Physically print out the passenger lists to permit check in and boarding. Most people book the flights well in advance; you can cope with most passengers with ease, even moving them between flights, if you have a backup paper system in place. Physically cross them off with the date and time you did it, then add them to a list that the gate staff can use. Card payment isn't an issue--most people already paid in advance; for those that didn't you can probably take the payment, physically document it and enter it into the system at a later time. It's absolutely doable, and any company who cares about surviving should have a system in place. The plant I worked at did this for legal and financial reasons. If a computer outage costs millions of pounds an hour, then you make sure it's covered. BA's outage likely cost much more than that.
The effect might not be immediate. It might not be noticeable or detectable for a few years, at which point it might be too late. Ecosystems are very complex, and can be fragile in ways we don't even suspect when some critical but unappreciated part is disrupted. When it concerns our future food production, it's only right to be concerned about it, irrespective of whether it eventually turns out to be a serious problem or not.
It really depends on what your priorities are. My current system is an FX-8350, and the new stuff does look like a really nice upgrade. It's definitely faster, and definitely more power efficient. But I do need to factor the cost of a new mainboard, CPU, RAM against keeping what I have. I'll pay more for the ongoing running cost in electricity usage for sure, but that usage is dwarfed by the replacement cost of all that hardware--it will take many years to break even. So I'll probably hold off for a year or so, and the cost of all the parts will be even cheaper by that point. I'd be in more of a rush to upgrade if what I had was noticeably bad, but the 8350 is a fine processor for everything I do, from gaming to compiling and running multi-threaded analysis code. While the new stuff would be nice for all these things, it's not sufficiently compelling to replace the hardware today.
Concorde used reheat only during take-off and then accelerating through the sound barrier. It definitely didn't use it for supercruise at Mach 2.2; at this speed the Olympus engines operated at their maximum efficiency--as designed.
It's not grammar that's the problem, it's basic spelling!
Kung Fury review and movie. If a single person with a small budget from Kickstarter can do that, then Hollywood should be orders of magnitude better. As it is, I found this more entertaining than the latest Iron Man or other Marvel stuff. I may just have questionable taste, but while this is a cheap and cheesy feature, it also quite clever--the whole thing is a parody of movie tropes, doesn't take itself seriously, and ticks a large number of boxes.
Exactly. If you're ethical, you won't leave any access possible, so there's no doubt as to your integrity. When I left my previous employer, a small business where I had full admin rights (I set most of it up), I made sure to wipe all my ssh keys, lock and delete my accounts so that the company directors could be sure I no longer had any access, remote or otherwise. No cron jobs, no source code, no customer information. A few months later they asked me if I could look into a problem that cropped up, and had to tell them it was impossible since I had no means to log in, but I could visit in person to briefly talk to their new staff. Mutual respect, and no possibility of any suspect practices due to being completely transparent about the leaving process. It's idiots like in TFA that give all of us a bad reputation, or at least cast a shadow of doubt upon our professionalism. Unfortunately, it's all too easy to do that if you don't want to act in good faith, particularly when you are entrusted with privileged access to a companies systems and processes.
You haven't had to compile for years. "pkg update; pkg install foo", as easy as Debian or Ubuntu.
Some electronic music, e.g. some trance, can be beautiful and subtle. But the best artists are often classically trained musicians, who can actually compose and arrange music. Both trance and classical music have very similar structure, so it makes sense that one can translate well to the other. For example, you can listen to some of Above & Beyond's early work like Tri-State, Sirens of the Sea performed by an orchestra; would have likely been better had it been written for an orchestra in the first place, but it showed that the various electronic instruments, effects etc. did almost directly translate to a classical setting. That said, there's an awful lot of crap out there, and being able to use a sequencer doesn't make you a gifted composer. I watched a youtube video of a trance producer last week going into how to use Ableton, and while interesting the result was terrible, almost as you say at pots and pans level.
I've read the pages where Microsoft attempt to justify this decision, e.g. https://blogs.msdn.microsoft.c.... I don't buy it. It's institutional laziness and resistance to change first and foremost. Choosing on a per-application basis whether to make it 32-bit or 64-bit is madness, especially in the situation here where you force every plugin and library being loaded to be 32-bit. You're developing a *system*, but it's really an agglomeration of different bits with little coherence or common direction. Linux distributions got this right. The whole installation is x86 or amd64. No confused mess of the two, x86 compat libs aside. We didn't agonise over minutiae, we did a complete conversion by treating them as two separate architctures, with biarch and multiarch for running legacy code. As is typical for Microsoft, they didn't have a transition plan, leaving much of their product line 32-bit only despite most developers and user having fully transitioned to x64 Windows over a decade or more back. Meanwhile on FreeBSD, Linux and MacOS X 32-bit is a distant memory on 64-bit platforms; the transition was done well over a decade back for many distributions as amd64 rebuilds were completed. What's tragic is they did the exact same thing with the 32-bit transition. Remember what a mess it was in the mid-90s to mid 2000s with a jumble of 16- and 32-bit code? It's exactly the same mess today with 32-bit and 64-bit code! They need some direction from the top to pull their fingers out and go 64-bit only, or do builds of both. If the BSD and Linux distros can build code for >10 architectures then I'm sure Microsoft can manage two, or three if we count their arm port (which is even more limited due to their x86 depenence, who would have expected that... Maybe build all your code on all architectures and x64 and arm could be first-class citizens.)
That should have read "But I've been badly bitten by *Btrfs* on several occasions..."; wish slashdot allowed editing of mistakes.
The device error correction is probabilistic. It won't necessarily know the data is "bad". And there can be firmware bugs which make it return or store bad data. What about phantom reads and writes. https://www.youtube.com/watch?... is a very interesting presentation from Bryan Cantrill about all sorts of bitrot and storage stuff.
When it comes to archival, ZFS is a production quality filesystem and volume manager intended for serious use. Btrfs is perpetually pre-alpha. Using it for archival would be foolish. It's also tied to a single implementation on a single operating system. I can (and have) run "zpool export" on a Linux server, removed the disks and slotted them into a FreeBSD server, then run "zpool import": data immediately on-line and mounted. It would also have worked for any other OS implementing ZFS; for data transportability it's the most feature cross-platform filesystem right now, given that the alternatives are crude filesystems like FAT. Archival implies the ability to read the data in a few decades, and I would bet that ZFS outlasts Btrfs by a significant margin. The single implementation of Btrfs might have been removed or changed incompatibly before you need to reread your data, and that presupposing that Btrfs wouldn't trash your data unrecoverably in the interim; after several total dataloss incidents with Btrfs due to implementation bugs in Btrfs, let's just say I'm a bit more grounded and objective as to its true merits.