Darwin, the core of Apple OS X, includes a virtual file system and network stack derived from the FreeBSD virtual file system and network stack
The network stack and VFS are kernel components. Other than that, though, you are correct, Darwin's kernel is XNU. But, wait a minute...
Originally developed by NeXT for the NeXTSTEP operating system, XNU was a hybrid kernel combining version 2.5 of the Mach kernel developed at Carnegie Mellon University with components from 4.3BSD and an Objective-C API for writing drivers called Driver Kit.
It seems that XNU is derived from BSD, alongside components from two other kernels.
After Apple acquired NeXT, the Mach component was upgraded to 3.0, the BSD components were upgraded with code from the FreeBSD project and the Driver Kit was replaced with a C++ API for writing drivers called I/O Kit.
You would have had to build a patched Bash from scratch on that system to secure it, as Apple only released patches for 10.7-10.9. Even if you were running a more recent version of OSX, you'd still have had to build it yourself to patch it *in time*. I'm really disappointed in Apple's response to this.
I never said no competently written code was affected, just that examples are exceedingly rare. Moreso, Toreo asesino's example was an application breaking as a result of patching this vulnerability, which would seem to indicate that said application was exploiting the vulnerability in the first place; zero competently written applications do that.
Yahoo's systems were _not_ compromised via the bash bug
This is what was being reported before I entered into two weeks of product launches that have kept me from following up. I'd thank you for the correction but you're a bit late with it, another poster already corrected me, and with much less snark.
FreeBSD does not use bash for/bin/sh
But that doesn't stop a sysadmin from changing that behavior, just as Unbuntu defaulting to Bash didn't stop me from swapping it our in favor of Dash. Just a matter of deleting the old binary and symlinking to the new one.
Apple's Darwin kernel was not forked from FreeBSD.
Oh, but it was! In fact, Darwin 7.0 (OSX 10.3) brought Darwin's BSD layer back in sync with FreeBSD 5. There was, indeed, a lot of reimplementation at the kernel level, and most of the userland tools had many parts rewritten as well, but your own source confirms what I have said. It confirmed it before I posted it originally, as well. In case that's not enough, here's another, and another, and, for good measure, one more, though that last one only mentions the use of BSD's userland components.
The patch didn't need patching, there were two separate exploits, one discovered during a decode review prompted by the other. There were actually 6 CVEs published about this, all of which can be found here. Might want to get your facts straight before you spout off.
If your applications are passing executable code as user-specifiable data that then gets passed as environment variables to a forked process that then spawns a system call eventually involving Bash, then you should be glad the patch broke it, as it just revealed a massive security vulnerability within your application. If you need that application to remain functional while you patch the issue, roll back to the previous version of Bash and work under the assumption that the gaping security hole that you're calling an application has already been compromised, because what it's doing is so much worse than Shellshock. More to the point, if your application were passing executable code or commands in this manner, the likely scenario is that you have some sort of command processor on the other end parsing and executing them; if you're exploiting Shellshock to accomplish this, you deserve prison time for gross negligence for A) incorporating the vulnerability into your application and B) not disclosing it so it could be patched.
At any rate, it's not a Linux issue, it's a Bash issue. Again, since Bash can run on *anything*, that makes it and "anything running Bash" issue, including your precious Windows in the majority of server environments, where a POSIX layer like Cygwin or MinGW (both of which include Bash) is likely to be in use.
Furthermore, simply having Bash installed does not make a system vulnerable; there has to be some service listening that passes unsanitized user-specified data as environment variables to a system call eventually handled by Bash. So surprisingly few competently written applications do this; GNU dhcpd was one, I'll give you that if you can give me another.
On the other hand you could do much worse on Linux using Bash to remotely gain control to a system with no administrator action required.
... but it was patched in under a week. The sysadmins who haven't applied the patches (which didn't require a reboot, or even so much as reloading the shell after installation) are the same ones who run Windows boxes so far behind on patches they're still remotely exploitable, too. Hell, they probably run Apache on Cygwin on Windows and never patched that, making their Windows box vulnerable to Shellshock. That's possible because, guess what, Bash isn't Linux and, in fact, predates Linux; Bash runs on *every* OS. Yes, even the iPhone can run Bash if you jailbreak it.
For the record, Yahoo, running FreeBSD, was compromised via Shellshock. Apple's Darwin kernel, which both OSX and iOS run on top of, was forked from the very same kernel Yahoo's servers run, and yes, OSX Yosemite is still waiting for a patch for Heartbleed, which means I have to keep a large number of services I'd like to be running disabled for the time being. My Linux servers, though, were all patched within hours; when an alternate exploit was found, they were once again patched in hours. I'm not even sure the Windows POSIX layers have released patched builds yet, so at this point Windows systems are more vulnerable to this than anything other production system (Yodsemite is still in beta, remember); fortunately, I don't run a POSIX layer on my Windows dev box.
oops... missed a linebreak in the volume/.distance example, it should read as follows:
3.333gal/100mi (equivalent to 30MPG), you drive 12,000 miles per year:
12000mi / 100mi = 120
120 * 3.333gal = 399.96gal (rounding error, since the fractional portion is actually nonterminating)
Your point did not come through *at all* in your original post. Moreso, volume/distance and distance/volume both suffer the flaw you just brought up; they're both variable based on driving conditions and the tune of the engine, along with hundreds of other variables. Likewise, your premise, as stated here:
Its trivial to compute yearly fuel costs in ones head using a volume per distance measure than distance per volume measure.
is equally wrong for a large portion of the populace. For example:
EPA rating 30MPG, you drive 12,000 miles per year:
12000mi / 30mpg = 400gal
Easy peasy.
3.333gal/100mi (equivalent to 30MPG), you drive 12,000 miles per year:
12000mi / 100mi = 120
120 * 3.333gal = 399.96gal (rounding error, since the fractional portion is actually nonterminating)
One step (divide), versus two (divide then multiply, or multiply then divide). Division by 100 is easy enough for most people so as to make it a moot point; even if we call both methods equal (which is the best case for your point), your point has been disproven.
Nah, you were just quick to comment and didn't notice that the == had all changed to !=. No worries, it happens; my comment was all in good fun, anyway.
How do you figure? If I get 30MPG and my tank holds 10 gallons, I know I can make any trip shorter than 300 miles on a full tank. Figuring out how far I can go on the fuel I have is simply a matter of multiplying gallons of fuel times MPG, the result being how many miles I can go. If my result is larger than the distance I need to travel, I can make it; if not, I'll need to get more fuel at some point.
If you're simply being pedantic, l/100km tells you just as much about whether you have enough gas to make a particular trip as MPG does; in either case you also need to know how much fuel you have available and the distance you must travel with that fuel.
While I generally agree with you, you're asking lazy people to do two calculations rather than one. It doesn't matter how simple 3.7/100 is, it's an extra step that most people aren't going to want. Over here, where we use gallons and miles, we also typically round both to integers, so figure:
GPM (3.7gal/100mi, rounded to 4gal/100mi):
1285mi * 4gal = 5140
5140 / 100mi = 51.5gal (rounded to 52gal)
OR
1285mi / 100mi = 12.85 (rounded to 13)
13 * 4 = 52gal
MPG (27.027mi/gal, rounded to 27mi/gal):
1285mi / 27mi = 47.593gal (rounded to 48gal)
MPG actually gives a more accurate result (in this case by nearly 10%) when using integer maths, which more people are actually capable of doing in their head, compared to decimal or fractional calculations.
the annoyance of transitioning over outweighs the benefits
Agreed. For starters, you only care about GPM when you're buying the car; when you need to know if the 5 gallons in your tank will take you 150 miles, you're better off knowing that you get 32MPG (that's 0.03125GMP), so yes, your 5gal will take you 150mi with 10mi to spare. If all you have is the GPM number, you can still figure it out, but your average American is confused by arithmetic involving decimal numbers and would never figure out that 0.03125gal * 150mi = 4.6875gal. 32 * 5 is difficult enough for most of us over here. Mind you, I calculate my mileage in my head at every fill up, so I'm not really including myself in that.
Too bad the argument really breaks down distance/volume vs volume/distance. In other words, the argument could be framed as MPG vs GPM or KPL vs LPK.
Express both using metric units and tell me, if you have to travel 1285km and your vehicle uses 3.7l/100km, or, rather, gets 27.027km/l, how much fuel do you need?
Do the math for both LPK and KPL, show your work. Here, I'll do it for you:
Just divide distance in miles by MPG (one operation)
20000km = 12427.4mi
12427.4mi / 18mpg = 690.4111gal
12427.4mi / 34mpg = 365.5118gal
When you invert it, you have to divide your overall distance by the denominator and multiply by the numberator (two operations):
20000km / 100km * 4l = 800l
20000km / 100km * 3l = 600l
OR
20000km * 3l / 100km = 800l
20000km * 3l / 100km = 600l
Yeah... LPK is much better than MPG. Well, actually since you have to convert between miles and kilometers, I can see that; you'd be better off using KPL in that case.
The additional step of negating the result is one more instruction which, depending on architecture, may be several CPU cycles; it's also one more CPU register used. Since the joke was relating to the main event loop of the program, that one extra instruction will have an impact on the performance of the system, as it is being executed on every single loop.
Be a lazy programmer. Save yourself 9 keystrokes and write more efficient code, both at the same time. It's really not hard. In fact, I didn't even set out to find that optimization, I immediately saw it when I looked at the code. Furthermore, the joke was that this was the main event loop; if your CPU is slow enough that you can only execute the event loop a few times per day, optimization is of the utmost importance, my friend.
My code:
Is it 2014? No: Enter Loop. Yes:
Is it October? No: Enter Loop. Yes:
Is it the 7th? No: Enter Loop. Yes: Break Loop.
Your code:
Is it the 7th? No: Return False. Yes:
Is it October? No: Return False. Yes:
Is it 2014? No: Return False. Yes: Return True
Negate the return value of the compound logic.
Is the negated value True? Yes: Enter Loop. No: Break Loop.
It would be more clear in a flow chart, but your code does a lot more branching than mine, and branching uses CPU cycles, as well as registers.
Slashdot Mirror
Hahahahahaha that's awesome! Now, does IIS pass headers along to CGI scripts the same way Apache does?
Holy shit if that's legit it's fucking amazing... booting my Win dev box now
Darwin, the core of Apple OS X, includes a virtual file system and network stack derived from the FreeBSD virtual file system and network stack
The network stack and VFS are kernel components. Other than that, though, you are correct, Darwin's kernel is XNU. But, wait a minute...
Originally developed by NeXT for the NeXTSTEP operating system, XNU was a hybrid kernel combining version 2.5 of the Mach kernel developed at Carnegie Mellon University with components from 4.3BSD and an Objective-C API for writing drivers called Driver Kit.
It seems that XNU is derived from BSD, alongside components from two other kernels.
After Apple acquired NeXT, the Mach component was upgraded to 3.0, the BSD components were upgraded with code from the FreeBSD project and the Driver Kit was replaced with a C++ API for writing drivers called I/O Kit.
Specifically, FreeBSD, after Apple took it over.
You would have had to build a patched Bash from scratch on that system to secure it, as Apple only released patches for 10.7-10.9. Even if you were running a more recent version of OSX, you'd still have had to build it yourself to patch it *in time*. I'm really disappointed in Apple's response to this.
I never said no competently written code was affected, just that examples are exceedingly rare. Moreso, Toreo asesino's example was an application breaking as a result of patching this vulnerability, which would seem to indicate that said application was exploiting the vulnerability in the first place; zero competently written applications do that.
Heh, looks like they did push an update for Yosemite on the 30th, too bad it's incomplete: Still vulnerable to exploit 7 on this page.
Available for: OS X Lion v10.7.5, OS X Lion Server v10.7.5, OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5
Yahoo's systems were _not_ compromised via the bash bug
This is what was being reported before I entered into two weeks of product launches that have kept me from following up. I'd thank you for the correction but you're a bit late with it, another poster already corrected me, and with much less snark.
FreeBSD does not use bash for /bin/sh
But that doesn't stop a sysadmin from changing that behavior, just as Unbuntu defaulting to Bash didn't stop me from swapping it our in favor of Dash. Just a matter of deleting the old binary and symlinking to the new one.
Apple's Darwin kernel was not forked from FreeBSD.
Oh, but it was! In fact, Darwin 7.0 (OSX 10.3) brought Darwin's BSD layer back in sync with FreeBSD 5. There was, indeed, a lot of reimplementation at the kernel level, and most of the userland tools had many parts rewritten as well, but your own source confirms what I have said. It confirmed it before I posted it originally, as well. In case that's not enough, here's another, and another, and, for good measure, one more, though that last one only mentions the use of BSD's userland components.
I meant Shellshock, which you probably could have guessed from context. My bad.
Thanks for the correction, I've been busy with product launches for the past 2 weeks so I haven't kept up.
Wow, did I really type "decode review". Shit. Well, you all know what I meant, anyway.
The patch didn't need patching, there were two separate exploits, one discovered during a decode review prompted by the other. There were actually 6 CVEs published about this, all of which can be found here. Might want to get your facts straight before you spout off.
If your applications are passing executable code as user-specifiable data that then gets passed as environment variables to a forked process that then spawns a system call eventually involving Bash, then you should be glad the patch broke it, as it just revealed a massive security vulnerability within your application. If you need that application to remain functional while you patch the issue, roll back to the previous version of Bash and work under the assumption that the gaping security hole that you're calling an application has already been compromised, because what it's doing is so much worse than Shellshock. More to the point, if your application were passing executable code or commands in this manner, the likely scenario is that you have some sort of command processor on the other end parsing and executing them; if you're exploiting Shellshock to accomplish this, you deserve prison time for gross negligence for A) incorporating the vulnerability into your application and B) not disclosing it so it could be patched.
At any rate, it's not a Linux issue, it's a Bash issue. Again, since Bash can run on *anything*, that makes it and "anything running Bash" issue, including your precious Windows in the majority of server environments, where a POSIX layer like Cygwin or MinGW (both of which include Bash) is likely to be in use.
Furthermore, simply having Bash installed does not make a system vulnerable; there has to be some service listening that passes unsanitized user-specified data as environment variables to a system call eventually handled by Bash. So surprisingly few competently written applications do this; GNU dhcpd was one, I'll give you that if you can give me another.
On the other hand you could do much worse on Linux using Bash to remotely gain control to a system with no administrator action required.
... but it was patched in under a week. The sysadmins who haven't applied the patches (which didn't require a reboot, or even so much as reloading the shell after installation) are the same ones who run Windows boxes so far behind on patches they're still remotely exploitable, too. Hell, they probably run Apache on Cygwin on Windows and never patched that, making their Windows box vulnerable to Shellshock. That's possible because, guess what, Bash isn't Linux and, in fact, predates Linux; Bash runs on *every* OS. Yes, even the iPhone can run Bash if you jailbreak it.
For the record, Yahoo, running FreeBSD, was compromised via Shellshock. Apple's Darwin kernel, which both OSX and iOS run on top of, was forked from the very same kernel Yahoo's servers run, and yes, OSX Yosemite is still waiting for a patch for Heartbleed, which means I have to keep a large number of services I'd like to be running disabled for the time being. My Linux servers, though, were all patched within hours; when an alternate exploit was found, they were once again patched in hours. I'm not even sure the Windows POSIX layers have released patched builds yet, so at this point Windows systems are more vulnerable to this than anything other production system (Yodsemite is still in beta, remember); fortunately, I don't run a POSIX layer on my Windows dev box.
oops... missed a linebreak in the volume/.distance example, it should read as follows:
3.333gal/100mi (equivalent to 30MPG), you drive 12,000 miles per year:
12000mi / 100mi = 120
120 * 3.333gal = 399.96gal (rounding error, since the fractional portion is actually nonterminating)
Its trivial to compute yearly fuel costs in ones head using a volume per distance measure than distance per volume measure.
is equally wrong for a large portion of the populace. For example:
EPA rating 30MPG, you drive 12,000 miles per year:
12000mi / 30mpg = 400gal
Easy peasy.
3.333gal/100mi (equivalent to 30MPG), you drive 12,000 miles per year:
12000mi / 100mi = 120 120 * 3.333gal = 399.96gal (rounding error, since the fractional portion is actually nonterminating)
One step (divide), versus two (divide then multiply, or multiply then divide). Division by 100 is easy enough for most people so as to make it a moot point; even if we call both methods equal (which is the best case for your point), your point has been disproven.
Nah, you were just quick to comment and didn't notice that the == had all changed to !=. No worries, it happens; my comment was all in good fun, anyway.
How do you figure? If I get 30MPG and my tank holds 10 gallons, I know I can make any trip shorter than 300 miles on a full tank. Figuring out how far I can go on the fuel I have is simply a matter of multiplying gallons of fuel times MPG, the result being how many miles I can go. If my result is larger than the distance I need to travel, I can make it; if not, I'll need to get more fuel at some point.
If you're simply being pedantic, l/100km tells you just as much about whether you have enough gas to make a particular trip as MPG does; in either case you also need to know how much fuel you have available and the distance you must travel with that fuel.
While I generally agree with you, you're asking lazy people to do two calculations rather than one. It doesn't matter how simple 3.7/100 is, it's an extra step that most people aren't going to want. Over here, where we use gallons and miles, we also typically round both to integers, so figure:
GPM (3.7gal/100mi, rounded to 4gal/100mi):
1285mi * 4gal = 5140
5140 / 100mi = 51.5gal (rounded to 52gal)
OR 1285mi / 100mi = 12.85 (rounded to 13)
13 * 4 = 52gal
MPG (27.027mi/gal, rounded to 27mi/gal):
1285mi / 27mi = 47.593gal (rounded to 48gal)
MPG actually gives a more accurate result (in this case by nearly 10%) when using integer maths, which more people are actually capable of doing in their head, compared to decimal or fractional calculations.
When did they release a 4cyl Metro?
the annoyance of transitioning over outweighs the benefits
Agreed. For starters, you only care about GPM when you're buying the car; when you need to know if the 5 gallons in your tank will take you 150 miles, you're better off knowing that you get 32MPG (that's 0.03125GMP), so yes, your 5gal will take you 150mi with 10mi to spare. If all you have is the GPM number, you can still figure it out, but your average American is confused by arithmetic involving decimal numbers and would never figure out that 0.03125gal * 150mi = 4.6875gal. 32 * 5 is difficult enough for most of us over here. Mind you, I calculate my mileage in my head at every fill up, so I'm not really including myself in that.
Too bad the argument really breaks down distance/volume vs volume/distance. In other words, the argument could be framed as MPG vs GPM or KPL vs LPK.
Express both using metric units and tell me, if you have to travel 1285km and your vehicle uses 3.7l/100km, or, rather, gets 27.027km/l, how much fuel do you need?
Do the math for both LPK and KPL, show your work. Here, I'll do it for you:
Using LPK (3l/100km):
1285km * 3.7l = 4754.5
4754.5 / 100km = 47.545l
OR
1285km / 100km = 12.85
12.85 * 3.7l = 47.545
Using KPL (27.027km/l):
1285km / 27.027km = 47.545l
<sarcasm level="severe">Yup, I see how volume/distance is so much easier.</sarcasm>
Just divide distance in miles by MPG (one operation)
20000km = 12427.4mi
12427.4mi / 18mpg = 690.4111gal
12427.4mi / 34mpg = 365.5118gal
When you invert it, you have to divide your overall distance by the denominator and multiply by the numberator (two operations):
20000km / 100km * 4l = 800l
20000km / 100km * 3l = 600l
OR
20000km * 3l / 100km = 800l
20000km * 3l / 100km = 600l
Yeah... LPK is much better than MPG. Well, actually since you have to convert between miles and kilometers, I can see that; you'd be better off using KPL in that case.
The additional step of negating the result is one more instruction which, depending on architecture, may be several CPU cycles; it's also one more CPU register used. Since the joke was relating to the main event loop of the program, that one extra instruction will have an impact on the performance of the system, as it is being executed on every single loop.
Be a lazy programmer. Save yourself 9 keystrokes and write more efficient code, both at the same time. It's really not hard. In fact, I didn't even set out to find that optimization, I immediately saw it when I looked at the code. Furthermore, the joke was that this was the main event loop; if your CPU is slow enough that you can only execute the event loop a few times per day, optimization is of the utmost importance, my friend.
Yes. But, you know as well as I do that these routers are running interpreted code for their interfaces. Suddenly, it matters again.
Step through that again, bud.
My code:
Is it 2014? No: Enter Loop. Yes:
Is it October? No: Enter Loop. Yes:
Is it the 7th? No: Enter Loop. Yes: Break Loop.
Your code:
Is it the 7th? No: Return False. Yes:
Is it October? No: Return False. Yes:
Is it 2014? No: Return False. Yes: Return True
Negate the return value of the compound logic.
Is the negated value True? Yes: Enter Loop. No: Break Loop.
It would be more clear in a flow chart, but your code does a lot more branching than mine, and branching uses CPU cycles, as well as registers.