The options are A) Spend $600 million to upgrade the infrastructure so there is enough bandwidth. B) Gain $600 million by not upgrading the infrastructure and just charge more for people who try to use it. This seems like a pretty easy decision for a business and, as long as all competitors choose option "B", there is no real risk of losing customers.
Honestly, I love all this scandal, digging up of skeletons, unexpected embarrassment, etc. It's kind of surreal to watch technology (and, its long and perfect memory) come back to haunt these deeply flawed candidates. I think the only way to fix the system is to discredit it so badly that both Democrat and Republican become toxic words. Toxic enough that the average person might want to distance themselves from whatever "tribe" they have chosen and instead elect people that they believe will *actually* represent them. Critical thinking is a lot to ask, I understand, but maybe technology is pushing us towards some sort of tipping point.
It could even be that the least error-prone way to do a simulation on such a large scale is to define the initial state of the universe and the laws of physics and then run the program at very high speed. Set breakpoints on emergent properties you might find interesting like macroscopic objects forming, the formation of heavier elements, self replicating molecules, life, etc. If none of your breakpoints get hit, tweak the initial state/laws and run it again. It would take a lot of hardware to do it this way but, the code seems pretty straightforward.
To me, it just seems a lot easier to coax a simulation into having the emergent properties you want rather than trying to program a universe scale version of The Sims.
- 1-2 grumpy old guys who are mostly just trying to steer the project away from disaster. - A couple guys a bit younger than that who are less jaded than the grumpy old guys but, kinda get where they are coming from and so genuinely think about the code they are writing. - A couple of young guys that just finished a C++ book and enthusiastically want to use templates everywhere.
That's a software team that can get shit done. And, probably won't be using the excuse of "refactoring" to rewrite it in six months.
Calm and rational discussion should be the norm, absolutely. No one argues with that. But, when someone fucks up, you don't hand them a lollipop and reassuringly pet their head.
When a kernel is released, it's *very* unlikely that it will see any use in a major distribution for 6 months to a year. And, by that time, it will be several revisions beyond the initial release. How does that compare to your dev/staging/production environment?
True. And, I can see your point. But, at the same time, it's well known that Linus behaves like this. Giving a pass to your right hand man *because* he's your right hand man is probably bad for the project. It's like saying, "Everyone who does something stupid will be called out. Except Andrew. I will just gloss over that".
I don't think it's cool as in, "Woohoo! Let's break out the popcorn and watch this guy burn at the stake!" but, it's the way the project is run. And, based on the fact that it's probably the most used single piece of software on the planet, I think you have to give a little leeway to the leadership and the devotion to perfection. Especially since, as I said, part of the reason Linus seems like a tyrant is that his business gets aired on public mailing lists as opposed to closed corporate e-mail accounts. He probably looks like a saint compared to your average CEO.
I understand that this is a troll post but, it still makes me laugh. Software guys over the age of 40 are a pain in the ass to work with because they've seen so much idiocy over their careers that they can spot it immediately and point it out. If you are in your 20s and working with other people in their 20s, the echo chamber you live in is certainly re-affirming but, not particularly conducive to writing good software.
If you'd been at the end of "Torvald's rampant verbal abuse" for 15 years, you'd have been banned from submitting to the kernel about 14.5 years ago. So, really, it wouldn't be an issue.
He's not apologizing. Saying "I'm sorry blank blank blank" doesn't constitute an apology.
What makes you think he was trying to apologize? He's highly irritated that one of his closest generals let something bad through. He reacted in normal Linus fashion but, I don't think you could get to where Andrew Morton is without being familiar with what Linus expects and how he reacts when his expectations aren't met. You have to have really, really thick skin to work at that level.
So, yeah, it wasn't polite. But, if you've ever worked at the higher levels of a big company, "polite" isn't even vaguely a consideration. The only reason that Linus rants make Slashdot news is because they happen in public. At any other company, a person in Andrew Mortons position is likely to be verbally berated but, it all happens behind closed doors.
If anything, in this case, people familiar with Andrew Morton probably find it slightly amusing that a Jedi Master can make mistakes too.
If I remember right, Andrew Morton has a Slashdot account so, maybe he can chime in.
Linus isn't likely to invite you out for an ice cream cone to discuss a bug and your feelings about it but, he's right that it's a pretty bad bug (http://lkml.iu.edu/hypermail/linux/kernel/1610.0/00878.html). Luckily, the way kernel development works means that 99.9999% of users will never see this bug. No major distro has shipped this yet and by the time this kernel trickles down to users (if ever), the bug will be fixed.
While chip alone may not be as secure as chip and pin, it is still more difficult to skim than the magnetic stripe.
I don't doubt that it's "more difficult" but, after a few years, will it prove to be "less frequent"? Probably not. If someone is determined to commit credit card fraud, the security that the chip provides is just a new technology to adapt to.
Further, the hardware change to chip is still required for chip and pin. It can always be implemented at a future point when the hardware migration is complete.
That's reasonable. But, they made the switch without adding the security part. If you are going to the trouble to redo the infrastructure of credit card processing, why not, I dunno, make it more secure while you do it? It's not like entering a PIN number is a foreign concept to people.
This "upgrade" is a complete farce. If they had moved to chip and pin then, yes, it would make sense for all businesses to adopt it. As it is, they moved from a "something you have" model to a slower "something you have" model. Without a "something you have and something you know" model, the upgrade is mostly just an inconvenience to all involved parties (except the credit card companies who can now defer more blame).
Because corporations are more sophisticated now. They realize they can take government subsidies for rolling out internet infrastructure and, when they don't actually deliver, there are no consequences.
I see a lot of the posts in this thread are people railing against Googles new surveillance device. Yet the majority of them probably have an Android phone sitting in their pocket. How is this any different? What makes this fundamentally worse?
Either you support this kind of device implicitly by carrying an Android (or iOS) phone or you don't support it by not carrying a phone at all. You can't have it both ways.
Contrary to the belief of nerds everywhere, intent matters a lot in court.
So does the law. If his lawyers claim that secondary infringement is not a criminal offense in the US is true, why is he being extradited to the US? What crime will he be accused of? How many years will he spend getting raped in prison for the facilitation of moving ones and zeros? What fundamental harm to our society has he done that warrants that?
My Debian system has 57 init scripts. If that kind of complexity scares you, perhaps computers are not for you.
Mine has 96, averaging 120 lines per script. I never said it scares me. I'm merely making fun of the aversion to Systemd's complexity, by highlighting the fact that you already have such complexity, but it's pushed out and duplicated (usually poorly) in your init scripts.
My grandparent post to this thread says that systemd has 374,000 lines of code in its git repo. You've described 11,500 lines of code, split into many different projects that is mostly boilerplate stuff. And, that's what systemd could actually do: Get rid of the boilerplate crap. As long as you did it in a sensible way, no one would argue with that. But, systemd reached Peak Sensibility like 7 or 8 years ago and has just devolved into... whatever it now is.
Yep. Using central Unix features like linking is the right way to do this. It utilizes the database-like aspects of the hierarchical filesystem, a central Unix feature that today you apparently take for granted.
...Requiring arcane naming schemes for numbering is the "right way"? Co-opting a folder to be a database is the "right way"? Treating your unsorted filesystem as a sorted list is the "right way"? My intent was to only make light of runlevels' inelegant implementation (and touch on their near-obsolescence, as well), but you've done more than that...
Hold on. Yes, that *is* the right way for most problems. You know who wrote my go-to database? Theodore Ts'o. You know who wrote my filesystem? Theodore Ts'o. You know who wrote my security software? The Linux Kernel Team.
Your problem is probably not a special snowflake problem. It has been solved before. Many, many times. And, on a modern computer, the incredible level of shit that you gain buy using the filesystem as your... well... everything, is amazing. Embrace the filesystem. It's your friend. Really.
I'm going to need a bit more proof than your authoritative claim, though. Besides being different, what's so wrong with it?
I take it that you have not looked at the actual code, afaik there is no nasty web of dependencies.
Really? Then why does the systemd project continue to consume higher level projects? Generally software projects don't decide, "Let's just consume all of our downstream users" unless they intend to fundamentally break the dependencies that the downstream users rely on. What systemd is doing is almost literally the definition of a clusterfuck.
Where there are dependencies they are on a documented DBUS service and not on a specific pid 1 and afaik there are no inter-project dependency either
Of course there are no inter-project dependencies: Systemd absorbed them all.
Yes, but that is what the XPoint technology is trying to address. The NVMe technology is not designed to operate like ram and the latencies are still very high. Nominal NVMe latency for a random access is 15-30uS. The performance (1.5-3.0 GBytes/sec for normal and 5 GBytes/sec+ for high-end NVMe devices, reading) comes from the multi-queue design allowing many requests to be queued at the same time.
Very few workloads would be able to attain the required request concurrency to actually max-out a NVMe device. You have to have something like 64-128 random requests outstanding to max-out the bandwidth (fewer for sequential). Server-side services have no problem doing this, but very few consumer apps can take full advantage of it.
The NVMe design is thus more akin to being a fast storage controller and should not be considered similar to a dynamic ram controller in terms of performance capability.
Because of the request concurrency required to actually attain the high read capability of a NVMe device, people shouldn't throw away their SATA SSDs just yet. Most SATA SSDs will actually have higher write bandwidth than low-end NVMe devices (particularly small form factor NVMe devices). And for a lot of (particularly consumer) workloads, the NVMe SSD will not be a whole lot faster.
That's very detailed and very interesting information. I didn't realize that the speed was related to how many requests could be queued up. It kind of sounds like these things are actually *a lot* slower than they appear but are very clever in hiding it. It kind of reminds me of when CPUs started getting prefetch instructions and compilers started generating them: You are hiding the latency by anticipating the access pattern.
That said, I really love NVMe, particularly when configured as swap and/or a swap-based disk cache. And I love it even more as a primary filesystem. It's so fast that I've had to redesign numerous code paths in DragonFlyBSD to be able to take full advantage of it. For example, the buffer cache and VM page queue (pageout demon) code was never designed for a data read rate of 5 GBytes/sec. Think about what 5+ GBytes/sec of new file-backed VM pages being instantiated per second does to normal VM page queue algorithms which normally only keep a few hundred megabytes of completely free pages in PG_FREE. The pageout demon couldn't recycle pages fast enough to keep up!
Its a nice problem to have:-)
-Matt
This is the kind of thing I was talking about in my original post. At some point it won't be enough to fix the (kinda amusing to have) bugs that result from ludicrously fast non-volatile memory. A new paradigm will be need to be addressed. And, I think it starts with anecdotes like you wrote and ends with a fundamental shift in how computers behave.
Sure, I figured the NVM probably stood for non-volatile memory but, it's still considered a storage medium and not a replacement for traditional RAM. When the line starts to blur between the two things is when we'll have new (and sometimes very old) paradigms starting to appear. I'm actually looking forward to it.
With desktops; you are also likely to have limited socket-compatible upgrade options, so getting a meaningful CPU boost often means swapping the motherboard as well(unless you started with the lousiest option for a given socket, in which case there might be meaningful improvements to be had)
This is almost always true with one exception: Xeon CPUs. The best bang for the dollar Xeon CPUs are usually in the $500 range while their high end counterparts are in the $2000 range. Building a dual Xeon workstation with $500 CPUs is painful but, building it with $2000 CPUs is insanity. However, if you wait about 3 years, you'll be able to pick up used $2000 CPUs for $200 on E-Bay. These CPUs are usually still "top 20-ish" on performance and still have many years of life left in them (Do CPUs even die these days?). When I did my upgrade, it was a pretty dramatic difference and, for $400, totally worth it. It extended the life of a really nice machine by several years.
Slashdot Mirror
The options are A) Spend $600 million to upgrade the infrastructure so there is enough bandwidth. B) Gain $600 million by not upgrading the infrastructure and just charge more for people who try to use it. This seems like a pretty easy decision for a business and, as long as all competitors choose option "B", there is no real risk of losing customers.
Honestly, I love all this scandal, digging up of skeletons, unexpected embarrassment, etc. It's kind of surreal to watch technology (and, its long and perfect memory) come back to haunt these deeply flawed candidates. I think the only way to fix the system is to discredit it so badly that both Democrat and Republican become toxic words. Toxic enough that the average person might want to distance themselves from whatever "tribe" they have chosen and instead elect people that they believe will *actually* represent them. Critical thinking is a lot to ask, I understand, but maybe technology is pushing us towards some sort of tipping point.
It could even be that the least error-prone way to do a simulation on such a large scale is to define the initial state of the universe and the laws of physics and then run the program at very high speed. Set breakpoints on emergent properties you might find interesting like macroscopic objects forming, the formation of heavier elements, self replicating molecules, life, etc. If none of your breakpoints get hit, tweak the initial state/laws and run it again. It would take a lot of hardware to do it this way but, the code seems pretty straightforward.
To me, it just seems a lot easier to coax a simulation into having the emergent properties you want rather than trying to program a universe scale version of The Sims.
Sure, an ideal software team is basically:
- 1-2 grumpy old guys who are mostly just trying to steer the project away from disaster.
- A couple guys a bit younger than that who are less jaded than the grumpy old guys but, kinda get where they are coming from and so genuinely think about the code they are writing.
- A couple of young guys that just finished a C++ book and enthusiastically want to use templates everywhere.
That's a software team that can get shit done. And, probably won't be using the excuse of "refactoring" to rewrite it in six months.
Calm and rational discussion should be the norm, absolutely. No one argues with that. But, when someone fucks up, you don't hand them a lollipop and reassuringly pet their head.
When a kernel is released, it's *very* unlikely that it will see any use in a major distribution for 6 months to a year. And, by that time, it will be several revisions beyond the initial release. How does that compare to your dev/staging/production environment?
Thought so...
True. And, I can see your point. But, at the same time, it's well known that Linus behaves like this. Giving a pass to your right hand man *because* he's your right hand man is probably bad for the project. It's like saying, "Everyone who does something stupid will be called out. Except Andrew. I will just gloss over that".
I don't think it's cool as in, "Woohoo! Let's break out the popcorn and watch this guy burn at the stake!" but, it's the way the project is run. And, based on the fact that it's probably the most used single piece of software on the planet, I think you have to give a little leeway to the leadership and the devotion to perfection. Especially since, as I said, part of the reason Linus seems like a tyrant is that his business gets aired on public mailing lists as opposed to closed corporate e-mail accounts. He probably looks like a saint compared to your average CEO.
I understand that this is a troll post but, it still makes me laugh. Software guys over the age of 40 are a pain in the ass to work with because they've seen so much idiocy over their careers that they can spot it immediately and point it out. If you are in your 20s and working with other people in their 20s, the echo chamber you live in is certainly re-affirming but, not particularly conducive to writing good software.
I'd revoke all my posts in this thread to mark this up...
If you'd been at the end of "Torvald's rampant verbal abuse" for 15 years, you'd have been banned from submitting to the kernel about 14.5 years ago. So, really, it wouldn't be an issue.
He's not apologizing. Saying "I'm sorry blank blank blank" doesn't constitute an apology.
What makes you think he was trying to apologize? He's highly irritated that one of his closest generals let something bad through. He reacted in normal Linus fashion but, I don't think you could get to where Andrew Morton is without being familiar with what Linus expects and how he reacts when his expectations aren't met. You have to have really, really thick skin to work at that level.
So, yeah, it wasn't polite. But, if you've ever worked at the higher levels of a big company, "polite" isn't even vaguely a consideration. The only reason that Linus rants make Slashdot news is because they happen in public. At any other company, a person in Andrew Mortons position is likely to be verbally berated but, it all happens behind closed doors.
If anything, in this case, people familiar with Andrew Morton probably find it slightly amusing that a Jedi Master can make mistakes too.
If I remember right, Andrew Morton has a Slashdot account so, maybe he can chime in.
Linus isn't likely to invite you out for an ice cream cone to discuss a bug and your feelings about it but, he's right that it's a pretty bad bug (http://lkml.iu.edu/hypermail/linux/kernel/1610.0/00878.html). Luckily, the way kernel development works means that 99.9999% of users will never see this bug. No major distro has shipped this yet and by the time this kernel trickles down to users (if ever), the bug will be fixed.
While chip alone may not be as secure as chip and pin, it is still more difficult to skim than the magnetic stripe.
I don't doubt that it's "more difficult" but, after a few years, will it prove to be "less frequent"? Probably not. If someone is determined to commit credit card fraud, the security that the chip provides is just a new technology to adapt to.
Further, the hardware change to chip is still required for chip and pin. It can always be implemented at a future point when the hardware migration is complete.
That's reasonable. But, they made the switch without adding the security part. If you are going to the trouble to redo the infrastructure of credit card processing, why not, I dunno, make it more secure while you do it? It's not like entering a PIN number is a foreign concept to people.
This "upgrade" is a complete farce. If they had moved to chip and pin then, yes, it would make sense for all businesses to adopt it. As it is, they moved from a "something you have" model to a slower "something you have" model. Without a "something you have and something you know" model, the upgrade is mostly just an inconvenience to all involved parties (except the credit card companies who can now defer more blame).
At that point, why not just use Cygwin?
Because corporations are more sophisticated now. They realize they can take government subsidies for rolling out internet infrastructure and, when they don't actually deliver, there are no consequences.
I see a lot of the posts in this thread are people railing against Googles new surveillance device. Yet the majority of them probably have an Android phone sitting in their pocket. How is this any different? What makes this fundamentally worse?
Either you support this kind of device implicitly by carrying an Android (or iOS) phone or you don't support it by not carrying a phone at all. You can't have it both ways.
Contrary to the belief of nerds everywhere, intent matters a lot in court.
So does the law. If his lawyers claim that secondary infringement is not a criminal offense in the US is true, why is he being extradited to the US? What crime will he be accused of? How many years will he spend getting raped in prison for the facilitation of moving ones and zeros? What fundamental harm to our society has he done that warrants that?
My Debian system has 57 init scripts. If that kind of complexity scares you, perhaps computers are not for you.
Mine has 96, averaging 120 lines per script. I never said it scares me. I'm merely making fun of the aversion to Systemd's complexity, by highlighting the fact that you already have such complexity, but it's pushed out and duplicated (usually poorly) in your init scripts.
My grandparent post to this thread says that systemd has 374,000 lines of code in its git repo. You've described 11,500 lines of code, split into many different projects that is mostly boilerplate stuff. And, that's what systemd could actually do: Get rid of the boilerplate crap. As long as you did it in a sensible way, no one would argue with that. But, systemd reached Peak Sensibility like 7 or 8 years ago and has just devolved into... whatever it now is.
Yep. Using central Unix features like linking is the right way to do this. It utilizes the database-like aspects of the hierarchical filesystem, a central Unix feature that today you apparently take for granted.
...Requiring arcane naming schemes for numbering is the "right way"? Co-opting a folder to be a database is the "right way"? Treating your unsorted filesystem as a sorted list is the "right way"? My intent was to only make light of runlevels' inelegant implementation (and touch on their near-obsolescence, as well), but you've done more than that...
Hold on. Yes, that *is* the right way for most problems. You know who wrote my go-to database? Theodore Ts'o. You know who wrote my filesystem? Theodore Ts'o. You know who wrote my security software? The Linux Kernel Team.
Your problem is probably not a special snowflake problem. It has been solved before. Many, many times. And, on a modern computer, the incredible level of shit that you gain buy using the filesystem as your... well... everything, is amazing. Embrace the filesystem. It's your friend. Really.
I'm going to need a bit more proof than your authoritative claim, though. Besides being different, what's so wrong with it?
Please see my previous posts in this article.
I take it that you have not looked at the actual code, afaik there is no nasty web of dependencies.
Really? Then why does the systemd project continue to consume higher level projects? Generally software projects don't decide, "Let's just consume all of our downstream users" unless they intend to fundamentally break the dependencies that the downstream users rely on. What systemd is doing is almost literally the definition of a clusterfuck.
Where there are dependencies they are on a documented DBUS service and not on a specific pid 1 and afaik there are no inter-project dependency either
Of course there are no inter-project dependencies: Systemd absorbed them all.
Yes, but that is what the XPoint technology is trying to address. The NVMe technology is not designed to operate like ram and the latencies are still very high. Nominal NVMe latency for a random access is 15-30uS. The performance (1.5-3.0 GBytes/sec for normal and 5 GBytes/sec+ for high-end NVMe devices, reading) comes from the multi-queue design allowing many requests to be queued at the same time.
Very few workloads would be able to attain the required request concurrency to actually max-out a NVMe device. You have to have something like 64-128 random requests outstanding to max-out the bandwidth (fewer for sequential). Server-side services have no problem doing this, but very few consumer apps can take full advantage of it.
The NVMe design is thus more akin to being a fast storage controller and should not be considered similar to a dynamic ram controller in terms of performance capability.
Because of the request concurrency required to actually attain the high read capability of a NVMe device, people shouldn't throw away their SATA SSDs just yet. Most SATA SSDs will actually have higher write bandwidth than low-end NVMe devices (particularly small form factor NVMe devices). And for a lot of (particularly consumer) workloads, the NVMe SSD will not be a whole lot faster.
That's very detailed and very interesting information. I didn't realize that the speed was related to how many requests could be queued up. It kind of sounds like these things are actually *a lot* slower than they appear but are very clever in hiding it. It kind of reminds me of when CPUs started getting prefetch instructions and compilers started generating them: You are hiding the latency by anticipating the access pattern.
That said, I really love NVMe, particularly when configured as swap and/or a swap-based disk cache. And I love it even more as a primary filesystem. It's so fast that I've had to redesign numerous code paths in DragonFlyBSD to be able to take full advantage of it. For example, the buffer cache and VM page queue (pageout demon) code was never designed for a data read rate of 5 GBytes/sec. Think about what 5+ GBytes/sec of new file-backed VM pages being instantiated per second does to normal VM page queue algorithms which normally only keep a few hundred megabytes of completely free pages in PG_FREE. The pageout demon couldn't recycle pages fast enough to keep up!
Its a nice problem to have :-)
-Matt
This is the kind of thing I was talking about in my original post. At some point it won't be enough to fix the (kinda amusing to have) bugs that result from ludicrously fast non-volatile memory. A new paradigm will be need to be addressed. And, I think it starts with anecdotes like you wrote and ends with a fundamental shift in how computers behave.
I didn't get around to responding to the GP post but, this is almost word for word what I would have said. Cheers!
Sure, I figured the NVM probably stood for non-volatile memory but, it's still considered a storage medium and not a replacement for traditional RAM. When the line starts to blur between the two things is when we'll have new (and sometimes very old) paradigms starting to appear. I'm actually looking forward to it.
With desktops; you are also likely to have limited socket-compatible upgrade options, so getting a meaningful CPU boost often means swapping the motherboard as well(unless you started with the lousiest option for a given socket, in which case there might be meaningful improvements to be had)
This is almost always true with one exception: Xeon CPUs. The best bang for the dollar Xeon CPUs are usually in the $500 range while their high end counterparts are in the $2000 range. Building a dual Xeon workstation with $500 CPUs is painful but, building it with $2000 CPUs is insanity. However, if you wait about 3 years, you'll be able to pick up used $2000 CPUs for $200 on E-Bay. These CPUs are usually still "top 20-ish" on performance and still have many years of life left in them (Do CPUs even die these days?). When I did my upgrade, it was a pretty dramatic difference and, for $400, totally worth it. It extended the life of a really nice machine by several years.