But they haven't! They are ramming C and sh down the average sysadmin's throat, without the slightest thought about what is appropriate for that sysadmin.
Don't be an ass. What they are doing is making sure that a default install of FreeBSD doesn't require a particular version of perl to be installed.
Great. You can go and add the one you want afterwards.
What is needed is a good, full-featured scripting language that the average sysadmin can master quickly. If I was paying to have my dream OS written, it would be Python, but Perl is good enough.
This is exactly what FreeBSD offers you. After you've installed it. Go add Python. You don't need to worry that the system relies on a particular version of Python, so you can install the one you want. In contrast to RedHat Linux which is wedded inseperably to Python 1.5.2, which has been out of data for about a millennia.
so once again somebody compares the newestr IDE against an older SCSI. How does iot compare to a 320? SCSI gigabit?
That's largely not the point. Apple aren't aiming for very high throughput, they're aiming for very large capacity.
From the apple website:
You wanted vast amounts of space for storing everything from high-definition video to large scientific datasets. Accordingly, Xserve holds nearly half a terabyte of data per machine -- and more than 20 terabytes per 42U rack.
Apple chose ATA100 because with a controller per drive it's fast enough and you can get 120GB IDE drives substantially cheaper than 36GB SCSI drives.
In general, scientific computing, video post-production, and 3D animation don't produce/consume data at high speeds, they produce/consume it in high quantities.
just a quick question about the rang() function. If you have a for loop with range(1000000) will it actually reserve that much memory just to do a long for loop, or is range interperetted like a counter?
If you use range then it allocates a list and populates it with the entire range of numbers requested. If you use xrange then it returns an object that implements the sequence protocol and looks like a list containing the appropriate range of numbers.
So:
for x in xrange( 1000000 ): print x
is like a standard for loop counting through a million iterations. Whereas the range equivalent would have created a million element list and then iterated over that.
Please find me where the code I posted is either incorrect (i.e., fails to give a correct result) or less than functional.:)
I knew I'd get pulled-up for using the word "correct";-) I meant to say that this is the standard functional formulation of the problem. You're point was that Python is readable, but the examples you gave are idiomatic and not the most readable versions.
I wrote it the way I wrote it because it's a terse, tail-recursive two-liner--admittedly, the tail recursion isn't the conventional Python style, but the fact that it's tail recursive is immediately evident.
Python doesn't optimise the tail recursion away, so the version you gave still eats stack. Given that you're not winning anything by being tail-recursive, you might as well go for the more standard mathematical form.
The reduce version is considerably slower than either of the two recursive versions, by the by, probably due to the time it takes for import to execute.
On the contrary, you'll see they both take exactly the same amount of time if you look more closely. The real value returned by time is a wall-clock figure, which doesn't represent the actual CPU time spent. The wall-clock figure will vary depending on what else the system was doing. The CPU time is the sum of the user and sys values - both of which are the same for the examples you gave.
You'll find that most of the time in your example is taken up with the initialisation of python itself - so your statistics aren't very useful. I tried this test timing just the evaluations of the two versions of fact and found the reduce version to be consistently about 7 times faster than the recursive version. The reduce version also works for an arbitrarily large n (especially if you change the range to xrange in my earlier posting), and is a rather neat one line.
The above samples cut-n-pasted from a Python interactive session also show more clearly how a new user would learn the language. Like the Good Old Days of computers that booted straight to BASIC interpreters, Python allows you to experiment with programming by just typing fragments of code at the prompt and trying them out.
Dell probably had very poor sales for Linux in the desktop segment. The people who buy these machines aren't the sort of people who would buy Linux - not because Linux isn't "ready for the desktop", but because they wouldn't know if it was.
Until you see Red Hat adverts featuring people flying through the air over green fields extolling the virtues of Linux for home users, you're not going to see much in the way of uptake.
The few people who do buy desktop boxen for running Linux are probably the kind of tech savvy people who already have Red Hat Linux CDs in the desk drawer and probably wouldn't want the default Dell install anyway.
I've got some pretty important.pgp files lying around. Should I switch to something else or am I not understanding something here?
It's probably quite worth getting gpg and seeing if it can work with your keys and encrypted files. One thing to note is that gpg doesn't support all of the algorithms that PGP used, because of patents/licensing (IDEA being an obvious example). So if you used those algorithms there's a serious risk of bitrot.
If gpg works OK with the files then you're safe as it's not likely to go away in a hurry. Keep the source around just in case though;-)
Strange, a lot of projects I'm familiar with don't use any one of those languages. I think it depends who you talk to.
You're talking about a relatively few open source projects. You have to remember that the vast majority of code (like 90% of all software written) is written entirely in-house by IT departments of organisations. This code never sees the light of day and you are unlikely to know anything about it unless you work for one of those organisations.
As someone else pointed out, IT departments are slowly shifting to the use of interpreted rapid development languages. Computers are fast enough and no-one wants the headache of maintaining large custom bodies of C/C++. [And before someone marks me as a troll, C and C++ are more difficult to maintain when you have limited IT resources. You need to be a very good programmer to write maintainable C and C++ code, and good programmers are few and expensive.]
The last large bank I worked at, pretty much every single new development project was being done in Java. That included web projects, desktop applications, back-end analytical servers, etc. For major places now the platform of choice is not a particular machine architecture, but a particular J2EE container. Microsoft realise this, that's why their throwing weight behind.NET.
Follow the money: Microsoft sell their development tools into in-house IT departments. At the aforementioned place I was working we were throwing out Visual C++ applications by the bucketload and redeveloping in Java. That means no new VC++ licenses and no need for MS applications servers. Microsoft wouldn't be doing it if they weren't very aware of which way the market is going.
Just to trump a project I'm involved in, The Arusha Project has some similar ideas to Jordan.
We use a simple XML file-based (i.e., you can edit everything with vi) object-oriented database. The project isn't just about package management, but we implemented a full multi-platform build-from-source-and-install-sitewide package management tool. It also handles dependencies etc.
[Bollocks! I had written a long thoughtful reply to this and it got eaten by the submission system. 2nd attempt...]
bandwagon and mindshare... CIOs have heard of Linux, not all of them have heard of *BSD. That's sad, because the BSDs are far more mature at a system level and I think they probably scale better. Then again, Sun and HP have Solaris and HP-UX for selling scalability.
An interesting question this point raises is: do IBM/HP/Sun consider Linux good enough to support small applications, but not good enough to be any real competition?
For instance: IBM sell special cheap zSeries processor nodes for running Linux VMs, but you can't buy a whole machine full of them. You still have to buy a "proper" node. They want you to run Linux beside zOS not instead of it. Clearly they're more worried about people running bind or Apache on non-IBM hardware than with people using Linux to do serious OLTP or something.
Is all this big guy support of Linux the equivalent of "damning with faint praise"?
Because Linux has mindshare and is a big buzzword at the moment. Make no mistake, the big guys are behind Linux because it's a good marketing move. I applaud the efforts of IBM, HP, and Sun in this regard - but one should be very careful before getting into bed with them.
Linux is a convenient tool for IBM to rescue their big iron from obscurity, for HP to save themselves from obscurity, and for Sun to sound like they're not falling behind IBM and HP.
There's an argument that picking a GPLed OS means that competitors can't commercialise their work, but I'm not convinced about this one. If you look closely, few lines of code have come out of these houses. They're much more interested in making sure that their hardware can run Linux, or Linux apps, than in supporting the general Open Source / Free Software movement. It's a careful play to ensure that if the OS ends up being commoditized, people don't pick Intel's hardware.
Given that one of the main brains behind Haskell now works for Microsoft Research and has always been a strong proponent of FP on commercial platforms - I'd be surprised as heck if the Glorious Haskell Compiler wasn't targetting.NET real soon.
I took a look around and found this link to a guy called Don Syme at Microsoft Research who appears to be working on just this.
There's also the Mondrian project, which implements Haskell.
Walking repeatedly and sequentially over All Memory + K tends to result in worse case performance. The reason is that when you hit the +K at the end of the loop you page out the oldest memory, which is the K at the beginning of the sequence. When you restart at the beginning you need to get this back in, so it pages out the next oldest K, which is of course the next part of the sequence. Thus you end up paging in and out the whole 1GB on each iteration, resulting in a massive slowdown.
(The real answer is less simplistic, but this is close enough to the truth.)
I don't know much about the US Patent Office, but the UK one has pretty sensible guidelines (from www.patent.gov.uk):
To be patentable your invention must:
* Be new
The invention must never have been made public in any way, anywhere in the world, before the date on which an application for a patent is filed.
* Involve an inventive step
An invention involves an inventive step if, when compared with what is already known, it would not be obvious to someone with a good knowledge and experience of the subject.
* Be capable of industrial application
An invention must be capable of being made or used in some kind of industry. This means that the invention must take the practical form of an apparatus or device, a product such as some new material or substance or an industrial process or method of operation.
"Industry" is meant in its broadest sense as anything distinct from purely intellectual or aesthetic activity. It does not necessarily imply the use of a machine or the manufacture of an article. Agriculture is included.
Articles or processes alleged to operate in a manner clearly contrary to well-established physical laws, such as perpetual motion machines, are regarded as not having industrial application.
* Not be "excluded"
An invention is not patentable if it is:
* a discovery;
* a scientific theory or mathematical method;
* an aesthetic creation such as a literary, dramatic or artistic work;
* a scheme or method for performing a mental act, playing a game or doing business;
* the presentation of information, or a computer program.
Also, again I don't know the situation in the states, but from the moment a patent has been filed - note: not granted - it is open to the public to examine. In fact a popular science programme on television here (Tomorrow's World) used to (may still) have a section called "Patent Pending" where they showcased interesting applications.
We seem to have far fewer stupid patents here. Although cross-border agreements to honour patents (largely driven by the US) are breaking down national legislation on this.
The success of any product depends on finding a customer base. You have to sell a certain number of units, or the product just won't survive.
Incorrect. It seems no-one is getting the point here. Apple did not design the iPod to be a smash consumer hit. They didn't even design it to be a cool music player. It was designed to be a cool extension of the Mac: Steve's "digital hub" strategy.
The point of the iPod is to make people buy Macs. Jesus, the margins on these things are so slim, even selling 100 million of them to PC owners would be a waste of Apple's time. Sony, Rio, Creative Labs, etc. are already doing that. It's not worth Apple competing with them.
What's really interesting is that Apple chose to make the iPod look like an HFS disk. There's no reason they couldn't have used something more standard
Bzzzzt! HFS+ is the standard for Macs. It seamlessly manages all of the legacy MacOS and UNIX meta-data that Apple require. Using any other filesystem makes absolutely no sense.
Let me make this absolutely clear:
The iPod is not meant to be used with a PC, with Windows, with Linux, with anything other than a spanking new shiny (30% margin) consumer Mac.
I'm a little fascinated by Slashdot's ongoing fixation on this device. [...] My only theory as to why is because it may not be Linux-y, but it's still a fascinating device.
Err... I think that pretty much covers it.
Since when did Slashdot become "News for Linux Weenies"? I thought this was a tech-head site. The iPod is most definitely a very cool toy from a techy perspective, which means it falls within the remit of this site.
In general you may have noticed that Apple are appearing increasingly frequently on Slashdot, which I guess means that they are doing things that are increasingly interesting to tech-heads, which I think is a good thing for Apple.
There were the same people harping on about the new iMac posting, saying what does it have to do with Slashdot. But any story that can generate a 1000 comments is clearly of interest to Slashdotters.
Apple have just released the latest version of their developer toolset (probably not available for non-seed download yet) and the main new cool thing is full support for writing Cocoa apps in AppleScript (AppleScript Developer Studio).
This is a very cool thing. For people who haven't heard of / used AppleScript before - it's a HyperTalk-type language (i.e., very verbose, almost natural language) that can be used to externally control and script many Mac OS applications. You can now basically throw together applications very quickly that have complex UI elements and interact with other applications and system components.
A neat feature is the ability to mix-and-match ObjC and AppleScript in the same application, so you can rapid prototype in AppleScript and then code complex sections in ObjC.
Hats off to Apple for throwing so much effort into a (IMHO) much overlooked technology. AppleScript is the key piece in a lot of custom workflow systems, and now a must-see for those who miss the old HyperCard days.
I don't have a great deal of personal experience with this, but at the last place I worked they had used Rogue Wave's Stingray Objective Toolkit as a cross-platform library for NT and Solaris.
I've heard bad things about it; I've heard good things about it. I couldn't comment either way.
I can't find it on their site now that I look, but I did find this:
SourcePro, which looks similar. They change the names of the products on a regular basis.
A point I've not seen anyone make is that the Hurd scales better than Linux ever will, and I don't mean in terms of hardware, I mean in terms of development.
Vast wars already take place about what should or should not be in the Linux kernel. The rate of progress on all of these fronts together is approaching glacial. There is just no easy way for a small team to keep a grip on a monolithic kernel that is being pulled in different directions by different developers. It has taken years for a journaling filesystem to be accepted into the kernel.
The Hurd neatly sidesteps all of these issues by not requiring any of these things to be in the kernel. Useful functionality like reiserfs and tux can be developed and released without any requirement for them to be "accepted" by any controlling group. At the moment, the only way to do something similar with Linux is to release a patch. This makes Linux much more susceptible to forking.
In case anyone disagrees with me on the forking issue, consider that Linux already has a very high profile fork: RedHat. RH have been distributing a forked kernel for a long time. Admittedly they only patch the kernel in minor ways, but nonetheless they maintain an alternative version. This is because if their views on what they want out of the OS differ from the kernel admins they have no choice but to fork.
But a RedHat version of GNU/Hurd could be composed of whatever OS servers they choose without any patching. They could mix and match the kernel distribution in much the same way as they currently mix and match the userspace distribution. Because most of the Hurd kernel *is* a userspace distribution.
To continue the doubt - I'd seriously doubt that it would be in Palm's interest to sue Microsoft. It would be an expensive distraction from their core business, which in case anyone didn't notice isn't doing that well at the moment anyway.
Yes, perhaps they could make a few bucks but it'd take years, and since (in my view) they don't plan to continue with BeOS on the desktop why bother flogging a dead horse?
...BeOS is dead. What on earth would Palm want to continue it for? There are pretty much no users and they add no value to Palm's core business. Palm wanted the assets: developer expertise, a useful codebase, a bunch of good ideas (and likely patents).
You can also forget about them open-sourcing the codebase - it's one of the assets they just bought. Presumably they see some kind of competitive advantage in having it (I'm not sure I do) - they're unlikely to give that away now.
Or for excellent parametric polymorphism, garbage collection, loads of useful API bindings, native compilation and lazy evaluation, try
Haskell. For the length example:
length [] = 0
length (x:xs) = 1 + length xs
More interesting examples use the lazy evaluation in Haskell to allow clean specification of algorithms without worry about trying to write the most efficient code. For instance if I wanted to sum the first ten numbers in the fibonacci sequence I might write:
fibonacci = (fib 0 1) where fib x y = x : fib y (x + y)
sum [] = 0
sum (x:xs) = x + sum xs
take 0 _ = []
take n (x:xs) = x : take (n-1) xs
sum_of_first_five = sum (take 10 fibonacci)
This program uses seemingly infinite recursion. However, thanks to lazy evaluation only the actual instructions that are required to evaluation the sum of the first five members will ever be run.
I'd recommend language hackers take a look at this elegant language. A Linux/Windows compiler is available as well as an interpreter for those who just want to tinker around with it. It even uses syntactic white space:-)
(Apologies to any Haskell hackers who spot mistakes in my code - it's been a while since I wrote any Haskell)
Slashdot Mirror
But they haven't! They are ramming C and sh down the average sysadmin's throat, without the slightest thought about what is appropriate for that sysadmin.
Don't be an ass. What they are doing is making sure that a default install of FreeBSD doesn't require a particular version of perl to be installed.
Great. You can go and add the one you want afterwards.
What is needed is a good, full-featured scripting language that the average sysadmin can master quickly. If I was paying to have my dream OS written, it would be Python, but Perl is good enough.
This is exactly what FreeBSD offers you. After you've installed it. Go add Python. You don't need to worry that the system relies on a particular version of Python, so you can install the one you want. In contrast to RedHat Linux which is wedded inseperably to Python 1.5.2, which has been out of data for about a millennia.
so once again somebody compares the newestr IDE against an older SCSI.
How does iot compare to a 320? SCSI gigabit?
That's largely not the point. Apple aren't aiming for very high throughput, they're aiming for very large capacity.
From the apple website:
You wanted vast amounts of space for storing everything from high-definition video to large scientific datasets. Accordingly, Xserve holds nearly half a terabyte of data per machine -- and more than 20 terabytes per 42U rack.
Apple chose ATA100 because with a controller per drive it's fast enough and you can get 120GB IDE drives substantially cheaper than 36GB SCSI drives.
In general, scientific computing, video post-production, and 3D animation don't produce/consume data at high speeds, they produce/consume it in high quantities.
For storage density IDE wins hands down.
just a quick question about the rang() function. If you have a for loop with range(1000000) will it actually reserve that much memory just to do a long for loop, or is range interperetted like a counter?
If you use range then it allocates a list and populates it with the entire range of numbers requested. If you use xrange then it returns an object that implements the sequence protocol and looks like a list containing the appropriate range of numbers.
So:
for x in xrange( 1000000 ):
print x
is like a standard for loop counting through a million iterations. Whereas the range equivalent would have created a million element list and then iterated over that.
Please find me where the code I posted is either incorrect (i.e., fails to give a correct result) or less than functional. :)
;-) I meant to say that this is the standard functional formulation of the problem. You're point was that Python is readable, but the examples you gave are idiomatic and not the most readable versions.
I knew I'd get pulled-up for using the word "correct"
I wrote it the way I wrote it because it's a terse, tail-recursive two-liner--admittedly, the tail recursion isn't the conventional Python style, but the fact that it's tail recursive is immediately evident.
Python doesn't optimise the tail recursion away, so the version you gave still eats stack. Given that you're not winning anything by being tail-recursive, you might as well go for the more standard mathematical form.
The reduce version is considerably slower than either of the two recursive versions, by the by, probably due to the time it takes for import to execute.
On the contrary, you'll see they both take exactly the same amount of time if you look more closely. The real value returned by time is a wall-clock figure, which doesn't represent the actual CPU time spent. The wall-clock figure will vary depending on what else the system was doing. The CPU time is the sum of the user and sys values - both of which are the same for the examples you gave.
You'll find that most of the time in your example is taken up with the initialisation of python itself - so your statistics aren't very useful. I tried this test timing just the evaluations of the two versions of fact and found the reduce version to be consistently about 7 times faster than the recursive version. The reduce version also works for an arbitrarily large n (especially if you change the range to xrange in my earlier posting), and is a rather neat one line.
The Python code, while similar in lines of code, is enormously clearer. If you're willing to write functional Python code, it's even better:
Erk. The correct functional formulation of this problem is:
>>> def fact( n ):
... if n == 0:
... return 1
... else:
... return n * fact( n - 1 )
...
>>> fact( 5 )
120
Or, more succinctly (and more stack efficient):
>>> import operator
>>> def fact( n ):
... return reduce( operator.mul, range(1, n+1) )
...
>>> fact(5)
120
The above samples cut-n-pasted from a Python interactive session also show more clearly how a new user would learn the language. Like the Good Old Days of computers that booted straight to BASIC interpreters, Python allows you to experiment with programming by just typing fragments of code at the prompt and trying them out.
Dell probably had very poor sales for Linux in the desktop segment. The people who buy these machines aren't the sort of people who would buy Linux - not because Linux isn't "ready for the desktop", but because they wouldn't know if it was.
Until you see Red Hat adverts featuring people flying through the air over green fields extolling the virtues of Linux for home users, you're not going to see much in the way of uptake.
The few people who do buy desktop boxen for running Linux are probably the kind of tech savvy people who already have Red Hat Linux CDs in the desk drawer and probably wouldn't want the default Dell install anyway.
This is almost completely off-topic, but I'm bored and I thought I'd give you a Fun Fact:
"Menzies" is an old scots name and was originally pronounced "Mingies" (soft, throaty "ng"). Still is pronounced that way in Scotland sometimes.
I've got some pretty important .pgp files lying around. Should I switch to something else or am I not understanding something here?
;-)
It's probably quite worth getting gpg and seeing if it can work with your keys and encrypted files. One thing to note is that gpg doesn't support all of the algorithms that PGP used, because of patents/licensing (IDEA being an obvious example). So if you used those algorithms there's a serious risk of bitrot.
If gpg works OK with the files then you're safe as it's not likely to go away in a hurry. Keep the source around just in case though
Strange, a lot of projects I'm familiar with don't use any one of those languages. I think it depends who you talk to.
.NET.
You're talking about a relatively few open source projects. You have to remember that the vast majority of code (like 90% of all software written) is written entirely in-house by IT departments of organisations. This code never sees the light of day and you are unlikely to know anything about it unless you work for one of those organisations.
As someone else pointed out, IT departments are slowly shifting to the use of interpreted rapid development languages. Computers are fast enough and no-one wants the headache of maintaining large custom bodies of C/C++. [And before someone marks me as a troll, C and C++ are more difficult to maintain when you have limited IT resources. You need to be a very good programmer to write maintainable C and C++ code, and good programmers are few and expensive.]
The last large bank I worked at, pretty much every single new development project was being done in Java. That included web projects, desktop applications, back-end analytical servers, etc. For major places now the platform of choice is not a particular machine architecture, but a particular J2EE container. Microsoft realise this, that's why their throwing weight behind
Follow the money: Microsoft sell their development tools into in-house IT departments. At the aforementioned place I was working we were throwing out Visual C++ applications by the bucketload and redeveloping in Java. That means no new VC++ licenses and no need for MS applications servers. Microsoft wouldn't be doing it if they weren't very aware of which way the market is going.
We use a simple XML file-based (i.e., you can edit everything with vi) object-oriented database. The project isn't just about package management, but we implemented a full multi-platform build-from-source-and-install-sitewide package management tool. It also handles dependencies etc.
That's the Glasgow Haskell Compiler, not Glorious.
Heh heh. I know. I was at Glasgow during a lot of it's development. "Glorious" was the local joke.
[Bollocks! I had written a long thoughtful reply to this and it got eaten by the submission system. 2nd attempt...]
bandwagon and mindshare... CIOs have heard of Linux, not all of them have heard of *BSD. That's sad, because the BSDs are far more mature at a system level and I think they probably scale better. Then again, Sun and HP have Solaris and HP-UX for selling scalability.
An interesting question this point raises is: do IBM/HP/Sun consider Linux good enough to support small applications, but not good enough to be any real competition?
For instance: IBM sell special cheap zSeries processor nodes for running Linux VMs, but you can't buy a whole machine full of them. You still have to buy a "proper" node. They want you to run Linux beside zOS not instead of it. Clearly they're more worried about people running bind or Apache on non-IBM hardware than with people using Linux to do serious OLTP or something.
Is all this big guy support of Linux the equivalent of "damning with faint praise"?
Because Linux has mindshare and is a big buzzword at the moment. Make no mistake, the big guys are behind Linux because it's a good marketing move. I applaud the efforts of IBM, HP, and Sun in this regard - but one should be very careful before getting into bed with them.
Linux is a convenient tool for IBM to rescue their big iron from obscurity, for HP to save themselves from obscurity, and for Sun to sound like they're not falling behind IBM and HP.
There's an argument that picking a GPLed OS means that competitors can't commercialise their work, but I'm not convinced about this one. If you look closely, few lines of code have come out of these houses. They're much more interested in making sure that their hardware can run Linux, or Linux apps, than in supporting the general Open Source / Free Software movement. It's a careful play to ensure that if the OS ends up being commoditized, people don't pick Intel's hardware.
Oops! forgot to mention that the "main brain" I referred to is the legendary Simon Peyton Jones.
I took a look around and found this link to a guy called Don Syme at Microsoft Research who appears to be working on just this.
There's also the Mondrian project, which implements Haskell.
Walking repeatedly and sequentially over All Memory + K tends to result in worse case performance. The reason is that when you hit the +K at the end of the loop you page out the oldest memory, which is the K at the beginning of the sequence. When you restart at the beginning you need to get this back in, so it pages out the next oldest K, which is of course the next part of the sequence. Thus you end up paging in and out the whole 1GB on each iteration, resulting in a massive slowdown.
(The real answer is less simplistic, but this is close enough to the truth.)
Also, again I don't know the situation in the states, but from the moment a patent has been filed - note: not granted - it is open to the public to examine. In fact a popular science programme on television here (Tomorrow's World) used to (may still) have a section called "Patent Pending" where they showcased interesting applications.
We seem to have far fewer stupid patents here. Although cross-border agreements to honour patents (largely driven by the US) are breaking down national legislation on this.
The success of any product depends on finding a customer base. You have to sell a certain number of units, or the product just won't survive.
Incorrect. It seems no-one is getting the point here. Apple did not design the iPod to be a smash consumer hit. They didn't even design it to be a cool music player. It was designed to be a cool extension of the Mac: Steve's "digital hub" strategy.
The point of the iPod is to make people buy Macs. Jesus, the margins on these things are so slim, even selling 100 million of them to PC owners would be a waste of Apple's time. Sony, Rio, Creative Labs, etc. are already doing that. It's not worth Apple competing with them.
What's really interesting is that Apple chose to make the iPod look like an HFS disk. There's no reason they couldn't have used something more standard
Bzzzzt! HFS+ is the standard for Macs. It seamlessly manages all of the legacy MacOS and UNIX meta-data that Apple require. Using any other filesystem makes absolutely no sense.
Let me make this absolutely clear:
The iPod is not meant to be used with a PC, with Windows, with Linux, with anything other than a spanking new shiny (30% margin) consumer Mac.
Why would BMW want to sell Ford accessories?
I'm a little fascinated by Slashdot's ongoing fixation on this device. [...] My only theory as to why is because it may not be Linux-y, but it's still a fascinating device.
Err... I think that pretty much covers it.
Since when did Slashdot become "News for Linux Weenies"? I thought this was a tech-head site. The iPod is most definitely a very cool toy from a techy perspective, which means it falls within the remit of this site.
In general you may have noticed that Apple are appearing increasingly frequently on Slashdot, which I guess means that they are doing things that are increasingly interesting to tech-heads, which I think is a good thing for Apple.
There were the same people harping on about the new iMac posting, saying what does it have to do with Slashdot. But any story that can generate a 1000 comments is clearly of interest to Slashdotters.
I use Linux too, but hey, take off the blinkers.
Apple have just released the latest version of their developer toolset (probably not available for non-seed download yet) and the main new cool thing is full support for writing Cocoa apps in AppleScript (AppleScript Developer Studio).
This is a very cool thing. For people who haven't heard of / used AppleScript before - it's a HyperTalk-type language (i.e., very verbose, almost natural language) that can be used to externally control and script many Mac OS applications. You can now basically throw together applications very quickly that have complex UI elements and interact with other applications and system components.
A neat feature is the ability to mix-and-match ObjC and AppleScript in the same application, so you can rapid prototype in AppleScript and then code complex sections in ObjC.
Hats off to Apple for throwing so much effort into a (IMHO) much overlooked technology. AppleScript is the key piece in a lot of custom workflow systems, and now a must-see for those who miss the old HyperCard days.
I don't have a great deal of personal experience with this, but at the last place I worked they had used Rogue Wave's Stingray Objective Toolkit as a cross-platform library for NT and Solaris.
I've heard bad things about it; I've heard good things about it. I couldn't comment either way.
I can't find it on their site now that I look, but I did find this: SourcePro, which looks similar. They change the names of the products on a regular basis.
A point I've not seen anyone make is that the Hurd scales better than Linux ever will, and I don't mean in terms of hardware, I mean in terms of development.
Vast wars already take place about what should or should not be in the Linux kernel. The rate of progress on all of these fronts together is approaching glacial. There is just no easy way for a small team to keep a grip on a monolithic kernel that is being pulled in different directions by different developers. It has taken years for a journaling filesystem to be accepted into the kernel.
The Hurd neatly sidesteps all of these issues by not requiring any of these things to be in the kernel. Useful functionality like reiserfs and tux can be developed and released without any requirement for them to be "accepted" by any controlling group. At the moment, the only way to do something similar with Linux is to release a patch. This makes Linux much more susceptible to forking.
In case anyone disagrees with me on the forking issue, consider that Linux already has a very high profile fork: RedHat. RH have been distributing a forked kernel for a long time. Admittedly they only patch the kernel in minor ways, but nonetheless they maintain an alternative version. This is because if their views on what they want out of the OS differ from the kernel admins they have no choice but to fork.
But a RedHat version of GNU/Hurd could be composed of whatever OS servers they choose without any patching. They could mix and match the kernel distribution in much the same way as they currently mix and match the userspace distribution. Because most of the Hurd kernel *is* a userspace distribution.
To continue the doubt - I'd seriously doubt that it would be in Palm's interest to sue Microsoft. It would be an expensive distraction from their core business, which in case anyone didn't notice isn't doing that well at the moment anyway.
Yes, perhaps they could make a few bucks but it'd take years, and since (in my view) they don't plan to continue with BeOS on the desktop why bother flogging a dead horse?
...BeOS is dead. What on earth would Palm want to continue it for? There are pretty much no users and they add no value to Palm's core business. Palm wanted the assets: developer expertise, a useful codebase, a bunch of good ideas (and likely patents).
You can also forget about them open-sourcing the codebase - it's one of the assets they just bought. Presumably they see some kind of competitive advantage in having it (I'm not sure I do) - they're unlikely to give that away now.
Or for excellent parametric polymorphism, garbage collection, loads of useful API bindings, native compilation and lazy evaluation, try
:-)
Haskell. For the length example:
length [] = 0
length (x:xs) = 1 + length xs
More interesting examples use the lazy evaluation in Haskell to allow clean specification of algorithms without worry about trying to write the most efficient code. For instance if I wanted to sum the first ten numbers in the fibonacci sequence I might write:
fibonacci = (fib 0 1) where fib x y = x : fib y (x + y)
sum [] = 0
sum (x:xs) = x + sum xs
take 0 _ = []
take n (x:xs) = x : take (n-1) xs
sum_of_first_five = sum (take 10 fibonacci)
This program uses seemingly infinite recursion. However, thanks to lazy evaluation only the actual instructions that are required to evaluation the sum of the first five members will ever be run.
I'd recommend language hackers take a look at this elegant language. A Linux/Windows compiler is available as well as an interpreter for those who just want to tinker around with it. It even uses syntactic white space
(Apologies to any Haskell hackers who spot mistakes in my code - it's been a while since I wrote any Haskell)