From what I understand, Windows CE is distributed much like other RTOS, complete source, but with big chunks missing for things that need to be developed for your specific hardware platform. A version for a JEDI probably isn't any more or less "special" than a Windows CE device from Casio. Also, I've heard that Microsofts royalies for Windows CE are really reasonable, probably comparing favorably to an eCos support contract.
When embedding perl into applications, libperl as a shared library starts to look attractive. (1MB isn't as bad when its shared across everything linked to libperl.so.
But I think that a perl built into the browser is a very bad idea. There are things that perl can do on my computer that I don't want some random web page designer to do. I once thought that the Safe module would be the answer to untrusted perl code, but there are some flaws in it that don't seem to be easily resolved.
I believe that the problems with Safe.pm caused a halt in Penguin (At the time that there was a big interest in Penguin, Felix was dismissing the advantage to embedding it into a browser. He wasn't saying that it couldn't be done, but just that it was the best use of network transported code.)
Why would you think they should be able to use our work and offer nothing in return?
They wouldn't be using your work, they'd be using Tanenbaum's work. And he seems to be OK with it.
Any licence, commercial, free, or whatever, pretty much boils down to If you give me {something}, you can use my code. If you are willing to give up what they want, fine. If you aren't willing to give up what the owner wants, don't complain, just turn them down and don't use it.
It funny. Just last Friday I was thinking I should look at MINIX for a project I was thinking about. I needed a half a dozen or so computers, but they didn't need to be particularly powerful or fast. x86 compatibility was going to be helpful, (reduce hardware design by using ISA for off the shelf things)
A '386 would be overkill, but I've seen single board 8086/8088s in the price range that I was looking for. But using an 8088 would have put Linux out of the running for a potential OS. And then I thought of MINIX. It seemed to fit perfectly to what I needed, so this announcement is something I'm really happy to hear.
Samba is implemented entirely in user space
on
Mac OS X And Samba?
·
· Score: 3
Samba is implemented entirely is user space. Little depends on the kernel out side of TCP sockets and POSIX file system calls. (Compare this to some version of Netatalk which require AppleTalk support in the kernel)
I don't see any reason why it couldn't work. I'm waiting until they put their "beige mac installer" software on their web site before I download a copy. If this question is still up in the air by then, I'll build it and let you know any problems I run into.
Porting software to new environments is a good test of its portability, and according to Kernigan and Pike in The Practice of Programming portable software tends to be more robust and better designed. Their comments revolve around the following ideas:
Programs tend to be used in unexpected environments. Planning for software to be more general results in easier maintainance later. (Similar to Brooks "Plan to throw one away. You will anyway.")
The development and deployment environment will change. Making a program portable to many different currently available environments will help against changes in future environments.
The techniques for creating portable software are similar to the general techniques for good programming. So the effort writing portable software will your software better.
So just think of the Cobolt port as a good test to make linux a better product in the future, even if you don't buy a cobolt.
Unfortunately, he seems to fall victim to a problem similar to the "not invented here". He makes comparisions and assumptions on performance based on how the feature might be implemented under Unix, not on any hard information on how they actually are implemented. He's looking at SIS with Unix colored glasses.
Hard links have certain features and limitations that pretty much fall out of the design of the original Unix filesystems. Hard links don't automatically protect backup programs from making two copies of the same file onto the backup (or worse restoring two copies on a disk where only one fit before.) the same way they aren't automatically protected from backing up a hole in a file.
Finding identical files under unix is difficult, not because the process itself is laborious, but because Unix doesn't have a "block until file changed" system call. Checking for file access from other processes involves some sort of polling. There is no reason a non-Unix API needs to have the same ommision.
Every time I hear someone talk about SIS, they always say that they are just the same as some feature (hard links,symlinks,NetApp's.snapshot, VMS versions, etc.) but then ignore the parts where it is different. If it is similar to a lot of different things, it must be different enough from any single one of them to deserve to be looked at as its own entity.
On the other hand, it is quite possible that MS botched the implementation in any number of ways. It could poll for changed file and be a huge performance hog. The backup APIs may be insufficient and backup software may mess up backing up files that have been SIS'd. It may make each individual workstation rely on the network. (I suspect that that the 80-90% space savings are due to a whole netowork of machines sharing a common c:\windows directory)
I'm not going to redicule the feature based on some slashdot thread claiming that Microsoft reinvented symbolic links. I'm also not going to claim that it can't work well until I can see how its implemented. I'm not going to believe it works well either.
I thought that there were some decisions against the copyrightability of function definitions. From what I've read, when Whitesmiths created IDRIS, they were worried about copyright infringement on Unix, so they renamed library routines and changed the order of argument lists. But later versions of IDRIS converted to Unix's standard calling conventions. I assumed it was because the issue had been settled elsewhere. (Or was it just because they realized that if Bell Labs wasn't going to sell it, they weren't going to sue over it.)
That is the purpose of Carbon. It is essentially a subset of the MacOS API, but isn't crippled by the limitations of the MacOS emulation subsystem. The change from Rhapsody to OSX was Carbon, and it was added specifically becuase some major MacOS developers had said that they would not rewrite their applications for the OpenStep APIs.
I don't know why you say that. Carbon is just a library that translates a subset Mac OS API calls into "Cocoa" API calls. And "Cocoa" is really Openstep which runs on Windows.
If there was a reason for Apple to want to make it easier for developers to create cross platform products, Carbon would be a great way for them to do it. That was the great appeal, to me, about the "Rhapsody" announcment. It pretty much read to me as:
Developers, you can either use awkward development environments (Visual C++) and baroque APIs (Win32) and try to sell to 95% of the desktop market, or you can bring your product to market sooner and use our great, timesaving development environment (Nextstep/Openstep development) and our rich and expressive API (Foundation Kit,Application Kit, etc.) and have a product that will reach 99% of the desktop market.
It was a good stratagy for a platform that was loosing market share in part because of its shrinking list of software and developers. Developers could shorten their development time, and as a side effect Apple got another product that ran on their platform. Of course, I can see why Cocoa was needed. The major mac developers said that they had no interest in rewriting for yellowbox/OSX. That if they were going to throw away their MacOS software, they weren't going to replace it with something else. And the promise of cross-platform compatibility didn't sell them either; they already had their cross-platform solutions worked out.
When the stategy turned from Rhapsody to OSX, the piece that really disturbed me was the dropping the royalty free Intel Yellowbox. The pieces still seem to be there. (Apple is still selling OpenStep for Windows), but the shift seemed only to try to win the favor of past MacOS developers (with Cocoa) rather than future developers (with a royalty free yellowbox)
I really doubt that its the microkernel that causes BeOS to be so fast. Microkernels are notorious for being slow. (Well, Mach is notorious for being slow, and Mach is the microkernel that has had the most research done with it. Every time someone talks about the lack of speed of Mach, they tend to imply "its just a microkernel thing", but they may just be giving other microkernels a bad name.) Some of the Mach papers that came with the MkLiux book seem to imply that Mach's slowness came from the its message passing architecture (from microkernel to server. A server being a kernel or a piece of a kernel.), and hinted at some ways in which it could optimize them into something only as expensive as a function call. No matter what, they were only hoping to make the microkernel into something that had the same speed as a traditional kernel. They weren't looking for a microkernel design to give them boosted performance.
I thought BeOS's speed was mainly due to very low latency thread dispatching.
Slashdot has been running "Geek Pride Day" advertisements for weeks.
If you haven't seen the banner ad, then all of Andover.net's adverstisers should probably start worrying about the exposure they're getting for their money.
I don't know what the pay involved is, I can imagine it is probably less than I a making now. But the bigger problem is that I feel that software patents are simply wrong, and could not bring myself to be granting a patent to anything consisting entirely of a computer program.
These arguments seem mostly against the patent office as it operates, rather than against their regulations say they should work. They are not supposed to allow patents which are either obvious ideas or can not actually be implemented
At one time, the patent office required an actual copy of the device to be given to the patent office. If they had to worry about where to actually store everything they approved a patent for, buying real estate, cataloging boxes, etc. (rather than just storing the paperwork) they would probably be much more careful about what they granted.
Software, since it is granting a patent to the process, would need to have an entire computer sent to the USPTO for storage, so the process could be demonstrated. Business method patents, with no actual devices would not be allowed patents because the USPTO would have nothing to put in the box.
James Gleick's article in the New York Times claims that the PTO gives bonuses based on productivity. I don't know how they measure productivity, patents approved or patents processed. (approved or rejected) I'm sure that "approved" would be quicker than "rejected" (rejecting would involve documentation to explain why.)
I don't quite buy the PTO being a patent factory, though. It seems to me that if they wanted to make the most money, they'd reject as many patents as possible, hoping that the patent applicants would fix their flaws and re-apply.
Where in the world did you read anything in which Bezos says that his patent covered "the whole look and feel of amazon's website"? The patent itself pretty much covers the type of thing one would think a "one click ordering" patent would.
Yes, Bezos is very eloquent in explaining his side of things. Thats how someone gets to be the head of a huge company with a huge stock market valuation while losing money hand over fist. The other side is pretty simple as well. Computers are machines that were developed to be infinitely configurable machines (the ultimate lego set, if you will.) Software configures the basic logic gates of the computer into some sort of form to perform an action. Software patents simply prohibit you from being able to configure your computer in a pattern of logic that it was designed to do. (If someone else has already built a yellow duck out of legos, then you aren't allowed to.)
Although the original purpose was promote the arts and sciences, it seems that they have been hijacked by large corporations. The government, taking the side with the most money, has perverted the intellectual property laws to continue to favor the corporations.
Just look at what has been do with copyright terms over the years. As soon as Mickey Mouse is about to enter the public domain, Congress extends the length of protection.
Someone would really have to go through a lot of work to masquarade as Matthew for a year before he writes cphack, unnoticed, in order for him to pretend to be him on Slashdot.
I've seen references to Weirdnix, a contest ran by the IEEE standards committee on the most bizarre way an implementation could be and still be legal POSIX. Basically how far could break the spirit of the document but still complient.
I've also heard that NT's subsystem would have been a winner if it was available at the time.
I based my "has already happened" comment on Usenet articles I've seen like this one Re: Linux vs FreeBSD
I've seen other references like this one, but this is the first that I could find on Deja. The story always revolves around elisp that was rewritten to avoid to avoid an employers claim on the work.
Since gcc is distributed under the GPL, derivitave works, including Apple's, need to be distrubted under a license compatible with the GPL. Apple's modified gcc is just as free as the one distributed by the FSF.
The FSF requires all patches that want to be considered for inclusion in the main development sources (rather than remaining as a fork) have their copyright assigned to the FSF. This is done to prevent a situation that they have run into in the past where companies have said that their employees have had no right to give the FSF code created on company property and time.
So the only interesting part of this announcement is that Apple is trying to minimize their own work of backpatching their changes into newer versions of gcc to maintain their own forked gcc.
At one time, the line was that Apple was a software vendor who needed to bundle their OS with hardware because what was around in the mass market wasn't adequate.
It may have been an exaggeration at the time, and they rest of the world has caught up. Fixed 64K segments, slow and awkward to configure ISA busses, 8250 UARTS, and MFM and RLL controllers and drives are mostly just bad dreams nowadays. And Apple was smart enough to use mass product hardware once the price and capability made sense to (IDE, compatibility with fixed frequency VGA monitors) or jump on the bandwagon of new standards to replace their own. (Nubus to PCI. ADB to USB)
On the software side, Apple has been saddled with a lot of their past mistakes. (Low level globals as an API to certain OS services) while losing some a lot of what originally made them great. (A Mac System Folder used to only require the files "System" and "Finder" in order to boot.)
So I'm not quite sure whether to classify Apple as a hardware or a software company. Their hardware doesn't have the differentiation that it used to, and they've let their software languish. I don't think Apple can either.
They did have a patent on Unix. At least the setuid portion of it.
It is number 4,135,240. Notice since that they described the process in terms of the logic gates of the memory chips involved, since at the time the USPTO prohibited patents on software.
Re:Un*x is also popular in real-time embedded syst
on
The End of Unix?
·
· Score: 1
Yes, there systems that run Unix that don't any of the user interface that most people think of as Unix, (bourne shell, popular X Window managers, etc.) many having no user interface at all.
But few Unix systems can handle the requirements for "real time"
Slashdot Mirror
From what I understand, Windows CE is distributed much like other RTOS, complete source, but with big chunks missing for things that need to be developed for your specific hardware platform. A version for a JEDI probably isn't any more or less "special" than a Windows CE device from Casio. Also, I've heard that Microsofts royalies for Windows CE are really reasonable, probably comparing favorably to an eCos support contract.
I found an article on perl5porters that describes most of the current problems http:/ /www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2 000-03/msg00760.html
When embedding perl into applications, libperl as a shared library starts to look attractive. (1MB isn't as bad when its shared across everything linked to libperl.so.
But I think that a perl built into the browser is a very bad idea. There are things that perl can do on my computer that I don't want some random web page designer to do. I once thought that the Safe module would be the answer to untrusted perl code, but there are some flaws in it that don't seem to be easily resolved.
I believe that the problems with Safe.pm caused a halt in Penguin (At the time that there was a big interest in Penguin, Felix was dismissing the advantage to embedding it into a browser. He wasn't saying that it couldn't be done, but just that it was the best use of network transported code.)
They wouldn't be using your work, they'd be using Tanenbaum's work. And he seems to be OK with it.
Any licence, commercial, free, or whatever, pretty much boils down to If you give me {something}, you can use my code. If you are willing to give up what they want, fine. If you aren't willing to give up what the owner wants, don't complain, just turn them down and don't use it.
It funny. Just last Friday I was thinking I should look at MINIX for a project I was thinking about. I needed a half a dozen or so computers, but they didn't need to be particularly powerful or fast. x86 compatibility was going to be helpful, (reduce hardware design by using ISA for off the shelf things)
A '386 would be overkill, but I've seen single board 8086/8088s in the price range that I was looking for. But using an 8088 would have put Linux out of the running for a potential OS. And then I thought of MINIX. It seemed to fit perfectly to what I needed, so this announcement is something I'm really happy to hear.
Samba is implemented entirely is user space. Little depends on the kernel out side of TCP sockets and POSIX file system calls. (Compare this to some version of Netatalk which require AppleTalk support in the kernel)
I don't see any reason why it couldn't work. I'm waiting until they put their "beige mac installer" software on their web site before I download a copy. If this question is still up in the air by then, I'll build it and let you know any problems I run into.
- Programs tend to be used in unexpected environments. Planning for software to be more general results in easier maintainance later. (Similar to Brooks "Plan to throw one away. You will anyway.")
- The development and deployment environment will change. Making a program portable to many different currently available environments will help against changes in future environments.
- The techniques for creating portable software are similar to the general techniques for good programming. So the effort writing portable software will your software better.
So just think of the Cobolt port as a good test to make linux a better product in the future, even if you don't buy a cobolt.Unfortunately, he seems to fall victim to a problem similar to the "not invented here". He makes comparisions and assumptions on performance based on how the feature might be implemented under Unix, not on any hard information on how they actually are implemented. He's looking at SIS with Unix colored glasses.
.snapshot, VMS versions, etc.) but then ignore the parts where it is different. If it is similar to a lot of different things, it must be different enough from any single one of them to deserve to be looked at as its own entity.
Hard links have certain features and limitations that pretty much fall out of the design of the original Unix filesystems. Hard links don't automatically protect backup programs from making two copies of the same file onto the backup (or worse restoring two copies on a disk where only one fit before.) the same way they aren't automatically protected from backing up a hole in a file.
Finding identical files under unix is difficult, not because the process itself is laborious, but because Unix doesn't have a "block until file changed" system call. Checking for file access from other processes involves some sort of polling. There is no reason a non-Unix API needs to have the same ommision.
Every time I hear someone talk about SIS, they always say that they are just the same as some feature (hard links,symlinks,NetApp's
On the other hand, it is quite possible that MS botched the implementation in any number of ways. It could poll for changed file and be a huge performance hog. The backup APIs may be insufficient and backup software may mess up backing up files that have been SIS'd. It may make each individual workstation rely on the network. (I suspect that that the 80-90% space savings are due to a whole netowork of machines sharing a common c:\windows directory)
I'm not going to redicule the feature based on some slashdot thread claiming that Microsoft reinvented symbolic links. I'm also not going to claim that it can't work well until I can see how its implemented. I'm not going to believe it works well either.
I thought that there were some decisions against the copyrightability of function definitions. From what I've read, when Whitesmiths created IDRIS, they were worried about copyright infringement on Unix, so they renamed library routines and changed the order of argument lists. But later versions of IDRIS converted to Unix's standard calling conventions. I assumed it was because the issue had been settled elsewhere. (Or was it just because they realized that if Bell Labs wasn't going to sell it, they weren't going to sue over it.)
That is the purpose of Carbon. It is essentially a subset of the MacOS API, but isn't crippled by the limitations of the MacOS emulation subsystem. The change from Rhapsody to OSX was Carbon, and it was added specifically becuase some major MacOS developers had said that they would not rewrite their applications for the OpenStep APIs.
I don't know why you say that. Carbon is just a library that translates a subset Mac OS API calls into "Cocoa" API calls. And "Cocoa" is really Openstep which runs on Windows.
If there was a reason for Apple to want to make it easier for developers to create cross platform products, Carbon would be a great way for them to do it. That was the great appeal, to me, about the "Rhapsody" announcment. It pretty much read to me as:
Developers, you can either use awkward development environments (Visual C++) and baroque APIs (Win32) and try to sell to 95% of the desktop market, or you can bring your product to market sooner and use our great, timesaving development environment (Nextstep/Openstep development) and our rich and expressive API (Foundation Kit,Application Kit, etc.) and have a product that will reach 99% of the desktop market.
It was a good stratagy for a platform that was loosing market share in part because of its shrinking list of software and developers. Developers could shorten their development time, and as a side effect Apple got another product that ran on their platform. Of course, I can see why Cocoa was needed. The major mac developers said that they had no interest in rewriting for yellowbox/OSX. That if they were going to throw away their MacOS software, they weren't going to replace it with something else. And the promise of cross-platform compatibility didn't sell them either; they already had their cross-platform solutions worked out.
When the stategy turned from Rhapsody to OSX, the piece that really disturbed me was the dropping the royalty free Intel Yellowbox. The pieces still seem to be there. (Apple is still selling OpenStep for Windows), but the shift seemed only to try to win the favor of past MacOS developers (with Cocoa) rather than future developers (with a royalty free yellowbox)
I thought BeOS's speed was mainly due to very low latency thread dispatching.
If you haven't seen the banner ad, then all of Andover.net's adverstisers should probably start worrying about the exposure they're getting for their money.
I don't know what the pay involved is, I can imagine it is probably less than I a making now.
But the bigger problem is that I feel that software patents are simply wrong, and could not bring myself to be granting a patent to anything consisting entirely of a computer program.
So they probably wouldn't want me anyway.
These arguments seem mostly against the patent office as it operates, rather than against their regulations say they should work. They are not supposed to allow patents which are either obvious ideas or can not actually be implemented
At one time, the patent office required an actual copy of the device to be given to the patent office. If they had to worry about where to actually store everything they approved a patent for, buying real estate, cataloging boxes, etc. (rather than just storing the paperwork) they would probably be much more careful about what they granted.
Software, since it is granting a patent to the process, would need to have an entire computer sent to the USPTO for storage, so the process could be demonstrated. Business method patents, with no actual devices would not be allowed patents because the USPTO would have nothing to put in the box.
I don't quite buy the PTO being a patent factory, though. It seems to me that if they wanted to make the most money, they'd reject as many patents as possible, hoping that the patent applicants would fix their flaws and re-apply.
Yes, Bezos is very eloquent in explaining his side of things. Thats how someone gets to be the head of a huge company with a huge stock market valuation while losing money hand over fist. The other side is pretty simple as well. Computers are machines that were developed to be infinitely configurable machines (the ultimate lego set, if you will.) Software configures the basic logic gates of the computer into some sort of form to perform an action. Software patents simply prohibit you from being able to configure your computer in a pattern of logic that it was designed to do. (If someone else has already built a yellow duck out of legos, then you aren't allowed to.)
Although the original purpose was promote the arts and sciences, it seems that they have been hijacked by large corporations. The government, taking the side with the most money, has perverted the intellectual property laws to continue to favor the corporations.
Just look at what has been do with copyright terms over the years. As soon as Mickey Mouse is about to enter the public domain, Congress extends the length of protection.
Someone would really have to go through a lot of work to masquarade as Matthew for a year before he writes cphack, unnoticed, in order for him to pretend to be him on Slashdot.
I've seen references to Weirdnix, a contest ran by the IEEE standards committee on the most bizarre way an implementation could be and still be legal POSIX. Basically how far could break the spirit of the document but still complient.
I've also heard that NT's subsystem would have been a winner if it was available at the time.
I've seen other references like this one, but this is the first that I could find on Deja. The story always revolves around elisp that was rewritten to avoid to avoid an employers claim on the work.
Since gcc is distributed under the GPL, derivitave works, including Apple's, need to be distrubted under a license compatible with the GPL. Apple's modified gcc is just as free as the one distributed by the FSF.
The FSF requires all patches that want to be considered for inclusion in the main development sources (rather than remaining as a fork) have their copyright assigned to the FSF. This is done to prevent a situation that they have run into in the past where companies have said that their employees have had no right to give the FSF code created on company property and time.
So the only interesting part of this announcement is that Apple is trying to minimize their own work of backpatching their changes into newer versions of gcc to maintain their own forked gcc.
At one time, the line was that Apple was a software vendor who needed to bundle their OS with hardware because what was around in the mass market wasn't adequate.
It may have been an exaggeration at the time, and they rest of the world has caught up. Fixed 64K segments, slow and awkward to configure ISA busses, 8250 UARTS, and MFM and RLL controllers and drives are mostly just bad dreams nowadays. And Apple was smart enough to use mass product hardware once the price and capability made
sense to (IDE, compatibility with fixed frequency VGA monitors) or jump on the bandwagon of new standards to replace their own. (Nubus to PCI. ADB to USB)
On the software side, Apple has been saddled with a lot of their past mistakes. (Low level globals as an API to certain OS services) while losing some a lot of
what originally made them great. (A Mac System Folder used to only require the files "System" and "Finder" in order to boot.)
So I'm not quite sure whether to classify Apple as a hardware or a software company. Their hardware doesn't have the differentiation that it used to, and they've let their software languish. I don't think Apple can either.
It is number 4,135,240. Notice since that they described the process in terms of the logic gates of the memory chips involved, since at the time the USPTO prohibited patents on software.
Yes, there systems that run Unix that don't any of the user interface that most people think of as Unix, (bourne shell, popular X Window managers, etc.) many having no user interface at all.
But few Unix systems can handle the requirements for "real time"