Linked by Thom Holwerda on Fri 25th Feb 2011 00:09 UTC
OSNews, Generic OSes Oh. My. God. When I read this, and browsed the website, my face went like this. Do you remember the Amiga? That fun little computer that was miles ahead of its competition, but in recent years has been dragged through the mud by one shady figure after the next? Here's a new one: Amiga, Inc., the one 'run' by Bill McEwen, has partnered with a company called IContain to slap the Amiga logo on a bunch of low-end, incredibly sad products. Whether this is another shady deal I don't know, but worthy of the Amiga? I don't think so. I'm not putting this in the Amiga category, by the way. I refuse to. Forget it. It's going into our generic category. Fitting. Update: As was pointed out over at, not only are these nothing more than brandless OEM products with Photoshopped logos, the website itself is just a standard, unmodified WordPress theme. Oi. Doesn't instil a lot of confidence, now, does it?
Permalink for comment 464037
To read all comments associated with this story, please click here.
RE[3]: Div
by silix on Fri 25th Feb 2011 21:31 UTC in reply to "RE[2]: Div"
Member since:

Sure, it makes sense for a lot of things, even serial ports.
it made sense in the in the context it was created - ie: simple devices, applications exchanging data (often between fork()'s of themselves, not even actual threads) uniformly via pipes and via files, and running in the shell which was the primary execution environment (so to present data to another console process or to present data to the user was the same)
but when a shell is just a frontend that can be either visual or textual, and when devices are not simple read/write ports any more, it actually makes more sense to let kernel and userland communicate via per object/device class differentiated (thus optimized, since the class-file and file-class double conversion is avoided) interfaces - and relegate the uniform treatment to where they really belong (individual shell tools)
under the hood the same is true, in a way, for Windows when you look at the device path.
windows uses the device path only wrt namespace management, does not apply the file abstraction to actual device handling
It's just a lot more obscure there.
just because a different rationale is followed than the unix basing one, api's are vaster and more varied and device classes are enforced, doesn not inherently mean "a lot more obscure"...
It's interesting to note though that network interfaces are NOT files on *nix.
(are they not? i spposed they are open-/close-/write-/read -'ed like any other file object) on the other hand, linux PROCesses are...
text files exported by the kernel...

Reply Parent Score: 2