I think that you've been confused by the screen images of the prototype version 2.0 firmware. Even then the calculator app would be trounced by my 29 year old Casio.
That's a rather silly comparison as most of the functionality you're talking about didn't exist when the Palm III came out... and none of them are core PDA functionality other than persistant memory.
You could say that the iPod Touch/iPhone is a better calculator than my old Casio FX-1200 (circa 1979) for the same reasons, except, of course, the core functionality of the calculator on the iPod touch isn't there and it's not scientific unlike the FX-1200.
Now, the Palm III has a good calendar, addressbook etc. and i easily expandable with 3rd party appications.. and you can write your own and compile them with the free, GCC based SDK and have full functionality and as much access as the other applications. They fit the capability of the hardware as well.
Now, the iP{od Touch,hone} now have a reasonable calendar and address book but that's only part of the functionality. There's no way of beaming the information to another person's device, for example and the calendar doesn't have multiple categories etc. The functionality still has some way to go on this front, which may be addressed to some degree by the version 2.0 firmware but it can't overcome some of the hardware deficiencies.
Actually, there's a second limitation which is not so often expressed and that is the lack of access to a filesystem.
This limitation of the SDK means that unless the 3rd party applications save persistant data on a remote network resource it can't save its state. (The only way around this, possibly, would be to ask the notes, calendar or addressbook applications to store the data.)
Of course, even without the problem of background tasks, it would make any shared key cryptographic applications impossible to implement (without hard-coded keys) or off-device storage.
> Most of this study is in the form of programmed TV courses, which can be rented or borrowed from tape _ * libraries. In fact most schooling--from first grade through college--consists of programmed TV courses or lectures via closed circuit. Students visit a campus once or twice a week for personal consultations or for lab work that has to be done on site. Progress of each student is followed by computer, which assigns end term marks on the basis of tests given throughout the term. Surprisingly, this actually is coming to pass. Already remote learning is taking root even on the elementary levels. Actually, this was already nacent in 1968 in the UK.
The Open University had just been set up who's students would study at home using study packs and lectures given via TV programmes broadcast on the BBC either in the morning or late at night when normal programming was not being broadcast.
Actually, at least in the days of the m68k based Palms, there was a few SDK based upon gcc, so the barrier to market was technically zero. You didn't have to buy CodeWarrior. Once you'd built your app you could distribute it for free as well.
The problem with PalmOS, however, was that the developer community generally charged way too much for their piddling little apps which on UNIX and Linux would have been free.
The problem with the iPhone/iPod Touch SDK isn't its price, it's free, it's the price of getting it distributed. Many people haven't noticed that the $99 for the standard developer option is actually an annual fee. This is not a barrier for commercial developers but it is for anyone who is altruistic and wants to develop open source apps using the same models as used on other hobbyist platforms.
Then there is the problem of getting the blessing from Apple, how long will this take? Will Apple block applications which don't fit their vision of what the iPhone/iPod Touch should do?
Eh... the racist part doesn't have anything to do with where he's from; it came from him using Ada...
Yes, how dare he use a language named after the lady friend of Sir Charles Babbage (Ada Lovelace) who was a pioneer of mathematical, algorithmic notation and thought!
Of course, the language was designed for use by that well known white supremisist organisation, the British Ministry of Defence, for use in suspressing other races, such as those with red flags during the cold war.
I've never understood why data centre designers haven't used a different cooling strategy to re-circulated cooled air. After all, for much of the temperate latitudes for much of the year the external ambient temperature is at or below that needed for the data centre so why not use conditioned external air to cool the equipment and then exhaust it (possibly with a heat exchanger to recover the heat for other uses such as geothermal storage and use in winter)? (Oh, and have the air-flow fans on the UPS.)
The advantage of this is that even in the worst case scenario where the chillers fail totally during mid-summer there is no run-away, closed loop, self re-enforcing heat cycle, the data centre temperature will rise but it would do so more slowly and the maximum equilibrium temperature will be far lower (and dependant upon the external ambient temperature).
In fact, as part of the design for the cluster room in our new building I've specified such a system, though due to the maximum size of the ducting space available we can only use this for half the heat load.
Of course, at the rate things are going they'll have to finish it after it's been shut down.
I'm sure the other partners in the ISS will have something to say as well, especially as their bits haven't arrived yet and the time allowed to do research has been curtailed due to the cancelling of the "lifeboat" crew return vehicle about 7 years ago, meaning that you can't have a full compliment of crew on the station.
Actually, it depends upon the generation of iPod ear buds.
I have two sets, the first came with my iPod Shuffle (mark I) which have a short-ish rod containing the cable. These have a great low-end response and sound pretty good. The second set came with my iPod nano (mark II) which have longer rods, these sound really tinny and are horrid.
Which means that it's more work for the core kernel developers... Which is the whole point of the original posting.
Separate the drivers currently in the kernel source ball out into a separate project and define a kernel/driver programming interface and that work is decreased hugely. The side effect would be that hardware companies would find it far easier to develop and maintain drivers so that their management may actually think it worth the resources they can afford to give it. Again, this has nothing to do with whether the drivers are open, closed, GPL'd or released with any other license or even fully public domain.
I didn't actually mention black-box binary-only drivers or even those not released under the GPL, that's a totally separate issue. This is a maintainability issue and the costs to companies to keep modifying their code almost every time there's a minor kernel version change.
If a company can assign programming resources once off for a driver project and not have to spend extra resources every few months just because of a change in the kernel interface then they will look far more kindly on the idea of developing a driver, be it GPL'd or not. Remember, Linux is a small player for the hardware people and hence only minimal budget can be allocated to any driver project. Recurring costs (other than for bug fixes) are a major financial barrier.
The problem is that with almost every minor kernel version revision the driver interface is changed, so any book that goes into print will already be almost worthless by the time it got into the shops.
This is why the current fluid kernel/driver interface specification is unsustainable and unmanagable in the long term (and why ultimately the kernel development process will bog down).
The solution? Simple, separate the core kernel from the drivers and produce a specification for the interface which only changes with the major kernel version. Then the kernel developers can concentrate on the pure internals of the kernel which no-one but them should need to know about and the work which currently takes place to recode the hundreds of drivers each time there's a tweek to the driver interface could be redirected to more productive efforts... and the patch load should be less as well.
There is a side benefit to this as well, the energy barrier for 3rd parties to write drivers would be lower and hence it would be far more likely that they'd actually write them rather than management seeing the driver maintenance and support costs being too high to bother because of the constant code churn.
I know that there are many people who will veremently disagree with this because of the dogma saying, "the kernel hackers know best about the kernel so they should be the same people as those who write the drivers." There will also be those who believe the dogma of, "but the driver interface needs to change often so as to be Better(tm) so you can't set the interface in stone."
Not quite the same as today's ATMs.
on
ATM Turns 40
·
· Score: 4, Informative
It should be noted that the ATM of that era wasn't quite what we have today.
Instead of having a card with a magnetic stripe which you would get back after the transaction it was a small, plastic coated punched card which would be swallowed by the machine and then sent back to the account holder afterwards. In other words, it was an emergency "I need £10 of cash" card.
I remember my Dad having one of these from the National Westminster Bank circa 1972. ATMs didn't really take off until the magnetic stripe cards came out in the late '70s/ early '80s.
Sorry to burst your bubble, the DPA doesn't allow for a catch-all clause of "any purpose," the purpose must be defined reasonably tightly. Any company who tries the "any purpose" clause in a form is in breach of the act (from what I remember of the course I went on).
Also, permission has to be given by the individual explicitly, it's an opt-in and not an opt-out.
Oh, and unlike the first DPA, the second version covers paper copies of information as well.
Indeed, and they were wrong as well. I wasn't trying to get at people from the USA, everyone should remember that Slashdot has a global audience and should make sure that everything is spelt out so that everyone can understand what's being discussed.
But seriously, could the authors of stories (or the Slashdot editorial staff) please remember that the readership aren't all based in the good ol'US of A and hence may not recognise the acronyms used, even if they are totally familiar to you. Surely adding the expansion in brackets after the first use of the term wouldn't hurt and it would help a large number of the readership (maybe even a slight majority) get the most out of the information being given. After all, information without a means of decoding it is merely data and is meaningless.
I believe this might be the second story today which could have benefited with such an explanation.
So, please could someone explain to those outside the USA what NCAA stands for?
As for the topic itself, it seems like the person broke the terms of the agreement he had with the authority who allowed him onto their property. He was a guest and hence when he broke their rules he was asked to leave the premises, just as any householder might if a guest disgraced themselves.
Slashdot Mirror
Not on my iPod Touch.
I think that you've been confused by the screen images of the prototype version 2.0 firmware. Even then the calculator app would be trounced by my 29 year old Casio.
Thank-you for clearing this up. Seeing as I'm not in the US I couldn't download the SDK and discover these things for myself.
That's a rather silly comparison as most of the functionality you're talking about didn't exist when the Palm III came out... and none of them are core PDA functionality other than persistant memory.
You could say that the iPod Touch/iPhone is a better calculator than my old Casio FX-1200 (circa 1979) for the same reasons, except, of course, the core functionality of the calculator on the iPod touch isn't there and it's not scientific unlike the FX-1200.
Now, the Palm III has a good calendar, addressbook etc. and i easily expandable with 3rd party appications.. and you can write your own and compile them with the free, GCC based SDK and have full functionality and as much access as the other applications. They fit the capability of the hardware as well.
Now, the iP{od Touch,hone} now have a reasonable calendar and address book but that's only part of the functionality. There's no way of beaming the information to another person's device, for example and the calendar doesn't have multiple categories etc. The functionality still has some way to go on this front, which may be addressed to some degree by the version 2.0 firmware but it can't overcome some of the hardware deficiencies.
Actually, there's a second limitation which is not so often expressed and that is the lack of access to a filesystem.
This limitation of the SDK means that unless the 3rd party applications save persistant data on a remote network resource it can't save its state. (The only way around this, possibly, would be to ask the notes, calendar or addressbook applications to store the data.)
Of course, even without the problem of background tasks, it would make any shared key cryptographic applications impossible to implement (without hard-coded keys) or off-device storage.
Surprisingly, this actually is coming to pass. Already remote learning is taking root even on the elementary levels. Actually, this was already nacent in 1968 in the UK.
The Open University had just been set up who's students would study at home using study packs and lectures given via TV programmes broadcast on the BBC either in the morning or late at night when normal programming was not being broadcast.
Indeed. I made an observation which collapsed the waveform. Oops.
Of course, in another time line I didn't post the comment.
I wonder when the first post with a ST:TNG reference will appear? :-)
Actually, this is pretty interesting science as well.
Actually, at least in the days of the m68k based Palms, there was a few SDK based upon gcc, so the barrier to market was technically zero. You didn't have to buy CodeWarrior. Once you'd built your app you could distribute it for free as well.
The problem with PalmOS, however, was that the developer community generally charged way too much for their piddling little apps which on UNIX and Linux would have been free.
The problem with the iPhone/iPod Touch SDK isn't its price, it's free, it's the price of getting it distributed. Many people haven't noticed that the $99 for the standard developer option is actually an annual fee. This is not a barrier for commercial developers but it is for anyone who is altruistic and wants to develop open source apps using the same models as used on other hobbyist platforms.
Then there is the problem of getting the blessing from Apple, how long will this take? Will Apple block applications which don't fit their vision of what the iPhone/iPod Touch should do?
Actually, you pay once *PER YEAR* to have the applications signed and on the iTunes store!
That's very different from a one time only one off fee.
Actually, it costs you $99 PER YEAR to give away your application(s).
Eh... the racist part doesn't have anything to do with where he's from; it came from him using Ada...
Yes, how dare he use a language named after the lady friend of Sir Charles Babbage (Ada Lovelace) who was a pioneer of mathematical, algorithmic notation and thought!
Of course, the language was designed for use by that well known white supremisist organisation, the British Ministry of Defence, for use in suspressing other races, such as those with red flags during the cold war.
I've never understood why data centre designers haven't used a different cooling strategy to re-circulated cooled air. After all, for much of the temperate latitudes for much of the year the external ambient temperature is at or below that needed for the data centre so why not use conditioned external air to cool the equipment and then exhaust it (possibly with a heat exchanger to recover the heat for other uses such as geothermal storage and use in winter)? (Oh, and have the air-flow fans on the UPS.)
The advantage of this is that even in the worst case scenario where the chillers fail totally during mid-summer there is no run-away, closed loop, self re-enforcing heat cycle, the data centre temperature will rise but it would do so more slowly and the maximum equilibrium temperature will be far lower (and dependant upon the external ambient temperature).
In fact, as part of the design for the cluster room in our new building I've specified such a system, though due to the maximum size of the ducting space available we can only use this for half the heat load.
Surely, you mean Leesti, near Lave?
Or what about Triganic Pu?
After all the Galactic Bank doesn't deal in piddling small change.
Of course, at the rate things are going they'll have to finish it after it's been shut down.
I'm sure the other partners in the ISS will have something to say as well, especially as their bits haven't arrived yet and the time allowed to do research has been curtailed due to the cancelling of the "lifeboat" crew return vehicle about 7 years ago, meaning that you can't have a full compliment of crew on the station.
Please mod this comment up, it far more informative and insightful than the grandparent.
Actually, it depends upon the generation of iPod ear buds.
I have two sets, the first came with my iPod Shuffle (mark I) which have a short-ish rod containing the cable. These have a great low-end response and sound pretty good. The second set came with my iPod nano (mark II) which have longer rods, these sound really tinny and are horrid.
Which means that it's more work for the core kernel developers... Which is the whole point of the original posting.
Separate the drivers currently in the kernel source ball out into a separate project and define a kernel/driver programming interface and that work is decreased hugely. The side effect would be that hardware companies would find it far easier to develop and maintain drivers so that their management may actually think it worth the resources they can afford to give it. Again, this has nothing to do with whether the drivers are open, closed, GPL'd or released with any other license or even fully public domain.
I didn't actually mention black-box binary-only drivers or even those not released under the GPL, that's a totally separate issue. This is a maintainability issue and the costs to companies to keep modifying their code almost every time there's a minor kernel version change.
If a company can assign programming resources once off for a driver project and not have to spend extra resources every few months just because of a change in the kernel interface then they will look far more kindly on the idea of developing a driver, be it GPL'd or not. Remember, Linux is a small player for the hardware people and hence only minimal budget can be allocated to any driver project. Recurring costs (other than for bug fixes) are a major financial barrier.
The problem is that with almost every minor kernel version revision the driver interface is changed, so any book that goes into print will already be almost worthless by the time it got into the shops.
This is why the current fluid kernel/driver interface specification is unsustainable and unmanagable in the long term (and why ultimately the kernel development process will bog down).
The solution? Simple, separate the core kernel from the drivers and produce a specification for the interface which only changes with the major kernel version. Then the kernel developers can concentrate on the pure internals of the kernel which no-one but them should need to know about and the work which currently takes place to recode the hundreds of drivers each time there's a tweek to the driver interface could be redirected to more productive efforts... and the patch load should be less as well.
There is a side benefit to this as well, the energy barrier for 3rd parties to write drivers would be lower and hence it would be far more likely that they'd actually write them rather than management seeing the driver maintenance and support costs being too high to bother because of the constant code churn.
I know that there are many people who will veremently disagree with this because of the dogma saying, "the kernel hackers know best about the kernel so they should be the same people as those who write the drivers." There will also be those who believe the dogma of, "but the driver interface needs to change often so as to be Better(tm) so you can't set the interface in stone."
It should be noted that the ATM of that era wasn't quite what we have today.
Instead of having a card with a magnetic stripe which you would get back after the transaction it was a small, plastic coated punched card which would be swallowed by the machine and then sent back to the account holder afterwards. In other words, it was an emergency "I need £10 of cash" card.
I remember my Dad having one of these from the National Westminster Bank circa 1972. ATMs didn't really take off until the magnetic stripe cards came out in the late '70s/ early '80s.
Sorry to burst your bubble, the DPA doesn't allow for a catch-all clause of "any purpose," the purpose must be defined reasonably tightly. Any company who tries the "any purpose" clause in a form is in breach of the act (from what I remember of the course I went on).
Also, permission has to be given by the individual explicitly, it's an opt-in and not an opt-out.
Oh, and unlike the first DPA, the second version covers paper copies of information as well.
P.S. by "they" I meant the people who submitted the article, not those who didn't know what Orkut was. (I didn't know what it was either.)
Indeed, and they were wrong as well. I wasn't trying to get at people from the USA, everyone should remember that Slashdot has a global audience and should make sure that everything is spelt out so that everyone can understand what's being discussed.
It probably doesn't have a BS Kite Mark.
But seriously, could the authors of stories (or the Slashdot editorial staff) please remember that the readership aren't all based in the good ol'US of A and hence may not recognise the acronyms used, even if they are totally familiar to you. Surely adding the expansion in brackets after the first use of the term wouldn't hurt and it would help a large number of the readership (maybe even a slight majority) get the most out of the information being given. After all, information without a means of decoding it is merely data and is meaningless.
I believe this might be the second story today which could have benefited with such an explanation.
So, please could someone explain to those outside the USA what NCAA stands for?
As for the topic itself, it seems like the person broke the terms of the agreement he had with the authority who allowed him onto their property. He was a guest and hence when he broke their rules he was asked to leave the premises, just as any householder might if a guest disgraced themselves.