There's only so much gas, bread, water and canned food you can practically store in your basement while you wait out the apocolypse. But gold you can store easily, and redeem when things go back to normal.
ZFS has xattrs which are close enough to streams. Aliases aren't part of the FS in HFS either. Case insensitivity is more part of the kernel's interpretation than the FS per se.
The one thing ZFS won't have is hard linked directories, which is needed for time machine.
One thing I heard is that ZFS actually has to copy an entire file if you even change one byte. That's got to be bad for many applications. It seems hard to believe, but that's what I read. Can anyone confirm?
I would hardly call Java slow by design. TCL or Bourne shell would be slow by design. It seems like C programmers, and C-like language programmers think everything except C and its ilk to be "slow by design".
Smart pointers are an essentially reference counting solution, with all its pitfalls. I don't doubt it works in 90% of scenarios, but when things get really complicated, things can get hairy.
In many legal systems, appeals are limited to matters of law, not matters of fact. At least in certain levels of the legal system. The highest courts don't want to bother themselves with deciding the facts, they want to spend their precious time on examining the law. Whether the RIAA has their paperwork in order is a matter of fact.
They're surely not dumb enough to do that to a computer in space. I mean, what if you need to do some burn calculations, and you can't get into it because of lockdown?
The study was carried out by an independent organisation with two identical Toyota sedans. So I think its trustworthy. I think there are reasons why a modern computer controlled engine can make use of a higher octane fuel to give better results. Maybe the optimal rating for a modern engine is a higher rating.
About the effect on the engine - some of it was more anecdotal about what mechanics were saying that they could tell the difference between cars run on premium compared to regular by the internals of the engine.
At the very least, if you are getting better fuel economy, you are burning less fuel. Less fuel = less carbon deposits.
I don't know how it is in the US, but here in Australia they've done fuel economy tests comparing E10, regular and high octane gas. It turns out that using high octane, what with better fuel consumption will probably cost you only a couple of hundred dollars more more than low octane in a year of running, and you'll make that back easily with less wear on your engine, less carbon buildup in the engine, and less repairs, and less trips to the gas station. E10 is even worse, and will probably actually cost you more at the pump AND stuff your engine up. Everybody should just use high octane fuel.
Won't work to save the oil unless you get every country to do the same. And whoever does it will severely reduce their lifestyle. So its politically devastating, and you need every country to take that leap. Good luck.
There are some things in Lisp that CPUs can do efficiently, that C can't guarantee to do efficiently. For example, tail recursion without growing the stack. You might say then that Lisp is "more like how the processor works". You might be surprised how close to C output a good Lisp compiler might get.
And there are plenty of things in C that have a lot of stuff going on under the bonnet too. malloc() for example can be quite a complex and inefficient call, that has to do a lot of housekeeping to find a block of the right size and stop fragmentation.
There are many reasons why a programming language lives and dies apart from its intrinsic merit. For example, in days past C was popular because CPU cycles were a lot more important than they are now, and memory sizes were a lot smaller than they are now. Java was popular because it looks like C, but fixes some C problems. C# the same, C++ the same, Objective-C the same. TCL became popular because it was attached to a convenient Tk library. Ruby is becoming popular because of the web page library that made it famous. None of these reasons actually say much about the goodness of the language. They are accidents of history. I mean, that monstrosity of a language - Perl actually became popular. If that doesn't prove that popularity doesn't prove goodness, I don't know what does.
If you're going to have crappy code anyway, you're probably better off with crappy lisp than crappy C. Apart from anything else, there'll probably be less of it.
And if you hire someone talented, they'll pick up Lisp just fine.
It seems to me that all the issues the author mentions could be solved with some library written over the top of sockets (and potentially other primitives like threads). Sockets are meant to be a low level interface, not to solve every problem.
The multi-home problem is real, but could be fixed with a relatively minor extension to the API, like IPV6 has been added in.
I don't see why you need to go to trial to get to the bottom of it. Linux development is out in the open and the code is out in the open. If there was anything to it, they could have shown us the code on day one.
Sure they were a respected UNIX vendor. They were the only serious choice at one time for Intel, and then they "owned" (sort of) the original UNIX rights. Doesn't mean they were the best or most wonderful or impressive vendor, but they were a serious vendor.
The UNIX war has been interesting. SGI and HP committed suicide via Itanium. Sun has been slowly slipping into nothingness, and now is disappearing into Oracle. Seemingly IBM is emerging winner, with Linux taking the low end...
But wait... Apple is shipping more UNIX systems than anybody else bar none. Sooner or later those with big UNIX investments may realise that it is actually Apple who is going to be their natural ally.
To some extent you are right. WHen you rewrite it there is a 50% chance you will stuff it up worse, and it costs a whole hell of a lot of money.
On the other hand there could be competitive advantages and/or productivity advantages to moving from a batch COBOL world to an online, always-on, web enabled modern infrastructure. How many times have we rung some company or ggovernment department, and they couldn't do something half rational because their computer system was way out of date?
Slashdot Mirror
Easy, take beer and babes with you in the space ship.
DRM and copy protection are not the same thing.
Besides, CD copy protection doesn't work much.
There's only so much gas, bread, water and canned food you can practically store in your basement while you wait out the apocolypse. But gold you can store easily, and redeem when things go back to normal.
Well here's the thing. Almost all Macs rely on FireWire and USB for storage beyond the builtin disk.
ZFS has xattrs which are close enough to streams. Aliases aren't part of the FS in HFS either. Case insensitivity is more part of the kernel's interpretation than the FS per se.
The one thing ZFS won't have is hard linked directories, which is needed for time machine.
One thing I heard is that ZFS actually has to copy an entire file if you even change one byte. That's got to be bad for many applications. It seems hard to believe, but that's what I read. Can anyone confirm?
I would hardly call Java slow by design. TCL or Bourne shell would be slow by design. It seems like C programmers, and C-like language programmers think everything except C and its ilk to be "slow by design".
Smart pointers are an essentially reference counting solution, with all its pitfalls. I don't doubt it works in 90% of scenarios, but when things get really complicated, things can get hairy.
I don't find it boring, but then I am geeky.
In many legal systems, appeals are limited to matters of law, not matters of fact. At least in certain levels of the legal system. The highest courts don't want to bother themselves with deciding the facts, they want to spend their precious time on examining the law. Whether the RIAA has their paperwork in order is a matter of fact.
They're surely not dumb enough to do that to a computer in space. I mean, what if you need to do some burn calculations, and you can't get into it because of lockdown?
It's a high profile fucking cult.
Here is the study here.....
The study was carried out by an independent organisation with two identical Toyota sedans. So I think its trustworthy. I think there are reasons why a modern computer controlled engine can make use of a higher octane fuel to give better results. Maybe the optimal rating for a modern engine is a higher rating.
About the effect on the engine - some of it was more anecdotal about what mechanics were saying that they could tell the difference between cars run on premium compared to regular by the internals of the engine.
At the very least, if you are getting better fuel economy, you are burning less fuel. Less fuel = less carbon deposits.
I don't know how it is in the US, but here in Australia they've done fuel economy tests comparing E10, regular and high octane gas. It turns out that using high octane, what with better fuel consumption will probably cost you only a couple of hundred dollars more more than low octane in a year of running, and you'll make that back easily with less wear on your engine, less carbon buildup in the engine, and less repairs, and less trips to the gas station. E10 is even worse, and will probably actually cost you more at the pump AND stuff your engine up. Everybody should just use high octane fuel.
Won't work to save the oil unless you get every country to do the same. And whoever does it will severely reduce their lifestyle. So its politically devastating, and you need every country to take that leap. Good luck.
How many C programmers use "restrict" everywhere that it could be used? Zero point zero.
Or how many use it anywhere at all for that matter? Probably like zero point one percent of programmers.
There are some things in Lisp that CPUs can do efficiently, that C can't guarantee to do efficiently. For example, tail recursion without growing the stack. You might say then that Lisp is "more like how the processor works". You might be surprised how close to C output a good Lisp compiler might get.
And there are plenty of things in C that have a lot of stuff going on under the bonnet too. malloc() for example can be quite a complex and inefficient call, that has to do a lot of housekeeping to find a block of the right size and stop fragmentation.
There are many reasons why a programming language lives and dies apart from its intrinsic merit. For example, in days past C was popular because CPU cycles were a lot more important than they are now, and memory sizes were a lot smaller than they are now. Java was popular because it looks like C, but fixes some C problems. C# the same, C++ the same, Objective-C the same. TCL became popular because it was attached to a convenient Tk library. Ruby is becoming popular because of the web page library that made it famous. None of these reasons actually say much about the goodness of the language. They are accidents of history. I mean, that monstrosity of a language - Perl actually became popular. If that doesn't prove that popularity doesn't prove goodness, I don't know what does.
If you're going to have crappy code anyway, you're probably better off with crappy lisp than crappy C. Apart from anything else, there'll probably be less of it.
And if you hire someone talented, they'll pick up Lisp just fine.
What APIs is it missing?
What is even more annoying than 1.5 on PPC, is that Intel Core Duo (32 bit) Intel macs are also doomed to 1.5 only.
Only those with Core 2 Duo get 1.6.
It seems to me that all the issues the author mentions could be solved with some library written over the top of sockets (and potentially other primitives like threads). Sockets are meant to be a low level interface, not to solve every problem.
The multi-home problem is real, but could be fixed with a relatively minor extension to the API, like IPV6 has been added in.
I don't see why you need to go to trial to get to the bottom of it. Linux development is out in the open and the code is out in the open. If there was anything to it, they could have shown us the code on day one.
Sure they were a respected UNIX vendor. They were the only serious choice at one time for Intel, and then they "owned" (sort of) the original UNIX rights. Doesn't mean they were the best or most wonderful or impressive vendor, but they were a serious vendor.
The UNIX war has been interesting. SGI and HP committed suicide via Itanium. Sun has been slowly slipping into nothingness, and now is disappearing into Oracle. Seemingly IBM is emerging winner, with Linux taking the low end...
But wait... Apple is shipping more UNIX systems than anybody else bar none. Sooner or later those with big UNIX investments may realise that it is actually Apple who is going to be their natural ally.
To some extent you are right. WHen you rewrite it there is a 50% chance you will stuff it up worse, and it costs a whole hell of a lot of money.
On the other hand there could be competitive advantages and/or productivity advantages to moving from a batch COBOL world to an online, always-on, web enabled modern infrastructure. How many times have we rung some company or ggovernment department, and they couldn't do something half rational because their computer system was way out of date?