Slot-loaded CD / DVD drives are long overdue in notebooks, anyhow [...]
On the contrary. On a powerbook -- with USB and FireWire to go -- anything is hot-pluggable, and the buses are (unlike on partial implementations of these interfaces) powered.
Why make the box larger and heavier if all you need is available when you need it, without you being forced to tug it along all the time you don't? Why build in swiftly outdating peripherals, if it's so easy and painless to just hook up the thing you need, and replace it with something newer when you feel compelled to do so, being a computer fashion slave?
Give me a PowerBook G3 (or G4; either is overkill for >99% of the work), with a FireWire DVD drive. Slotloading will do. All that needs to be built in is AirPort, that spiffy 100Mbit ethernet interface, USB and FireWire. Modems are evill retro-technology. Less is more. Dead weight is waste. Unused space is waste. Begone, builtin peripherals!
You don't even need Terminal.app; any telnet or ssh client will do. Including existing ssh or telnet clients, running in the Classic environment, seamlessly integrated.
and here's to hoping that Apple will open up all OSX, at least in some fashion or another.
Not gonna happen guys.
It already did -- all of OS X "plumbing" did just get released. And more: Darwin includes a significantly beefed up gcc, and -- and this is breathtaking -- Apple's Objective C runtime, and the CoreFoundation frameworks (well, almost all of them).
The rest -- AppKit, Kernel Extension/Driver Development Kit, Quartz, Quicktime (w. native OpenGL), Carbon, the full Java- and Objective C Cocoa frameworks and development tools -- depends quite a lot on having a powerful and versatile micro-architecture. Maybe it'll be there, at some point, and maybe it won't; but even in its current form, Darwin is already way ahead of all the rest. It actually has an architecture, and quality OO-frameworks that deliver.
One, a good reason for porting and cross-developing software -- including OS software -- is that it provides a relatively easy quality test: the better the abstraction from the underlying, and the fewer assumptions based on that creep into production code, the more robust, reliable and maintainable the code.
Darwin, or its predecessors, have always been built for Intel. As well as several other platforms. This has also been relatively simple: hardware abstraction is, to a great extent, offered by the microkernel. There simply is no driver purgatory like there is in monolithic OSes.
Drivers are an important issue. Writing them is a pain. It's difficult and hazardous, and, on OSes of a lesser design device drivers put the entire system at risk. On OS X, however, you get full driver protection, and a high-level development environment for drivers and kernel extensions on the side; and these can be added, or removed, from a running kernel, just like that.
I'll have that, thanks. No thanks, you can keep your monolithic, russian-roulette spaghetti-coded Unix lookalikes; I'd rather go for the real thing, with a solid architecture at its core and an unrivalled contemporary development environment-cum-frameworks (ProjectBuilder, Interface Builder, Object Modeler, Foundation Kit, AppKit) to go. It compiles (and runs) everything Unix as is, but more importantly, it goes way, way beyond. And '70s Unix may be good enough for some, but well, it's just '70s Unix to me. More, please, but more importantly: better, please. An environment that values *my* time, please. Yes, I'll order a few. To go. Make it snappy, please.
$ configure --host=`/usr/libexec/config.guess` [...]
On the contrary. On a powerbook -- with USB and FireWire to go -- anything is hot-pluggable, and the buses are (unlike on partial implementations of these interfaces) powered.
Why make the box larger and heavier if all you need is available when you need it, without you being forced to tug it along all the time you don't? Why build in swiftly outdating peripherals, if it's so easy and painless to just hook up the thing you need, and replace it with something newer when you feel compelled to do so, being a computer fashion slave?
Give me a PowerBook G3 (or G4; either is overkill for >99% of the work), with a FireWire DVD drive. Slotloading will do. All that needs to be built in is AirPort, that spiffy 100Mbit ethernet interface, USB and FireWire. Modems are evill retro-technology. Less is more. Dead weight is waste. Unused space is waste. Begone, builtin peripherals!
You don't even need Terminal.app; any telnet or ssh client will do. Including existing ssh or telnet clients, running in the Classic environment, seamlessly integrated.
It already did -- all of OS X "plumbing" did just get released. And more: Darwin includes a significantly beefed up gcc, and -- and this is breathtaking -- Apple's Objective C runtime, and the CoreFoundation frameworks (well, almost all of them).
The rest -- AppKit, Kernel Extension/Driver Development Kit, Quartz, Quicktime (w. native OpenGL), Carbon, the full Java- and Objective C Cocoa frameworks and development tools -- depends quite a lot on having a powerful and versatile micro-architecture. Maybe it'll be there, at some point, and maybe it won't; but even in its current form, Darwin is already way ahead of all the rest. It actually has an architecture, and quality OO-frameworks that deliver.
Funny how some things fail to get mentioned.
One, a good reason for porting and cross-developing software -- including OS software -- is that it provides a relatively easy quality test: the better the abstraction from the underlying, and the fewer assumptions based on that creep into production code, the more robust, reliable and maintainable the code.
Darwin, or its predecessors, have always been built for Intel. As well as several other platforms. This has also been relatively simple: hardware abstraction is, to a great extent, offered by the microkernel. There simply is no driver purgatory like there is in monolithic OSes.
Drivers are an important issue. Writing them is a pain. It's difficult and hazardous, and, on OSes of a lesser design device drivers put the entire system at risk. On OS X, however, you get full driver protection, and a high-level development environment for drivers and kernel extensions on the side; and these can be added, or removed, from a running kernel, just like that.
I'll have that, thanks. No thanks, you can keep your monolithic, russian-roulette spaghetti-coded Unix lookalikes; I'd rather go for the real thing, with a solid architecture at its core and an unrivalled contemporary development environment-cum-frameworks (ProjectBuilder, Interface Builder, Object Modeler, Foundation Kit, AppKit) to go. It compiles (and runs) everything Unix as is, but more importantly, it goes way, way beyond. And '70s Unix may be good enough for some, but well, it's just '70s Unix to me. More, please, but more importantly: better, please. An environment that values *my* time, please. Yes, I'll order a few. To go. Make it snappy, please.
Thanks.