Palm WebOS, Google Android, and Maemo are three ready examples of mainstream products that run Linux on ARM.
All with different "native" APIs, targeted to the handheld. You're not going to need ARM forks in your desktop binaries any more than you're going to get ARM forks in your Universal Binaries so you can run your desktop apps on your iPhone.
We have application makers who provide a binary installer for the Windows platform, yet hand Linux users a completely unpackaged BZ2 Type Tarball and say "Good luck!"
That's because you don't have to descend into the hell that is rpmbuild, which was a pile of rotting dingo fetuses ten years ago and hasn't gotten one bit better since.
It's long past time that they gave up that ghastly binary blob and defined a new "rpmx" format, that would look kind of like this:
A gzipped or bzipped tarball, containing:
1. a directory "common", containing roughly what you currently get from rpm2cpio. 2. a file "common.files", containing processed and massaged %files 3. a file "common.pre", containing %pre 4. a file "common.post", containing %post... etc N. a directory "i386" and "i386.files" etc, containing the platform specific x86 stuff N+1. same for "x86_64".
No weird binary format. No spec file full of a decade and a half of broken historical cruft. No requirement that you set up a chrooted environment to be sure you've got a clean environment for building the frigging RPM. Build it in perl or your scripting language of choice (even with a Makefile and shell scripts if you're old-school).
Why have universal binaries when you have Java to do that?
If I don't care about performance I can already write in Perl, Awk, Python, Tcl, or something. Why do I want to put up with Java?
I would LOVE to be able to remove all the "if `uname -cokebottle` matches "[xX]86" pick this RPM else pick that RPM" code from my installers. OK, that still leaves a fair amount of packaging hell unfixed but every little bit helps.
Kind of, but not really. No more than there are four architectures (PPC, ARM, X86, X86_64) for OS X. There's two architectures for Linux that actually matter, and they're the same two that run Snow Leopard. X86 and X86_64.
I can see why people are going to get up in arms about this. I've been as big a RISC booster as anyone, I think Apple gave up on PPC too soon, and I'm still bitter about Alpha, but that game's over. 32-bit and 64-bit Intel architectures are what matter, and those are the ones that almost all binaries will work for. I'm not running YDL any more, and neither are you. Game's over, instruction sets lost to marketing. The game's over, the fat lady's sung, picked up her paycheck, and gone home to watch House on her Tivo. Give it up and quit holding up the bus.
Who needs Ghost, we did it using a picoBSD boot floppy that dd-ed an image of the partition table and system partition onto the raw hard disk over... damn, I forget whether we used nfs or ssh or http now... and then ran setsid after first boot.
I guess your Sharepoint isn't using all the "features" of ours. I can't edit shared documents or even use all the pulldown options on documents unless I'm using IE.
"One thing that really impacts the crew's day-to-day operations is if the file server itself fails. This forces them to reload the hard drive and re-establish all the network drives and all the apps. They actually have to get out the media and load the image to the hard drive. That's a significant hit for the crew because we can't do everything for them from the ground.
Jesus Christ, given the cost per minute keeping those guys up there, I'd think they'd at the very least have redundant servers with redundant media.
The simple fact is - that if the source ain't open then the 'standards' can't be open.
Yes, you can have open standards implemented with closed source. TCP/IP, for example, was a closed source open standard before KA9Q and others implemented their own versions.
An open standard, however, can't be defined by a closed source implementation (eg, OOXML), and an open standard can't require licenses for documentation or distribution. And it's the latter that this particular change is aimed at... letting European standards bodies that make money from licensing standards play in the sandpit along with kids who really DO share well with others.
Apple's target market aren't going to put up with the kinds of shenanigans it takes to get a hackintosh running, whether or not they pull this kind of stuff.
Virtualization doesn't change the legal requirement that you have a separate license for each instance of a virtual machine you create. This has nothing to do with copying in RAM... your VM instance has a separate copy on disk as well.
Slashdot Mirror
So for OSX you count oldies (PPC) and embedded (ARM for the iphone) but for Linux you dismiss them ?
No, I dismiss them for both.
The neighbor playlist on last.fm is a really effective tool for finding stuff I didn't know about but like.
See, kids, this is why you need to read the thread before posting. :)
You wouldn't need ARM in your FatELF binaries because of Android any more than you need ARM in Universal binaries because of the iPhone.
By "lots" you mean what... a few hundred installations worldwide? Or a few hundred systems even?
They had nothing in the pipeline to compete with the coming Core 2 Duo.
They sure as hell did. That's precisely what the e700 was all about.
Well maybe what we could use instead in C byte code, or some other form of byte code, and then have on the JIT low-level compilations.
Even with good JIT you're looking at a factor of 2-5 performance hit.
And the "CPU architecture" issue is a red herring. We need FatELF for i386/x86_64 desktops, not for embedded processors.
Are makefiles and shell scripts considered "old school" nowadays?
Oh yeh, if it doesn't have lot's of <angle brackets> it might as well be bronze helmets and ox ploughs. :P
Palm WebOS, Google Android, and Maemo are three ready examples of mainstream products that run Linux on ARM.
All with different "native" APIs, targeted to the handheld. You're not going to need ARM forks in your desktop binaries any more than you're going to get ARM forks in your Universal Binaries so you can run your desktop apps on your iPhone.
IBM was never going to provide enough low-power PPC chips to Apple. Never.
Freescale was, however.
We have application makers who provide a binary installer for the Windows platform, yet hand Linux users a completely unpackaged BZ2 Type Tarball and say "Good luck!"
That's because you don't have to descend into the hell that is rpmbuild, which was a pile of rotting dingo fetuses ten years ago and hasn't gotten one bit better since.
It's long past time that they gave up that ghastly binary blob and defined a new "rpmx" format, that would look kind of like this:
A gzipped or bzipped tarball, containing:
1. a directory "common", containing roughly what you currently get from rpm2cpio. ... etc
2. a file "common.files", containing processed and massaged %files
3. a file "common.pre", containing %pre
4. a file "common.post", containing %post
N. a directory "i386" and "i386.files" etc, containing the platform specific x86 stuff
N+1. same for "x86_64".
No weird binary format. No spec file full of a decade and a half of broken historical cruft. No requirement that you set up a chrooted environment to be sure you've got a clean environment for building the frigging RPM. Build it in perl or your scripting language of choice (even with a Makefile and shell scripts if you're old-school).
Why have universal binaries when you have Java to do that?
If I don't care about performance I can already write in Perl, Awk, Python, Tcl, or something. Why do I want to put up with Java?
I would LOVE to be able to remove all the "if `uname -cokebottle` matches "[xX]86" pick this RPM else pick that RPM" code from my installers. OK, that still leaves a fair amount of packaging hell unfixed but every little bit helps.
On Linux, withe a couple of dozen architectures,
Kind of, but not really. No more than there are four architectures (PPC, ARM, X86, X86_64) for OS X. There's two architectures for Linux that actually matter, and they're the same two that run Snow Leopard. X86 and X86_64.
I can see why people are going to get up in arms about this. I've been as big a RISC booster as anyone, I think Apple gave up on PPC too soon, and I'm still bitter about Alpha, but that game's over. 32-bit and 64-bit Intel architectures are what matter, and those are the ones that almost all binaries will work for. I'm not running YDL any more, and neither are you. Game's over, instruction sets lost to marketing. The game's over, the fat lady's sung, picked up her paycheck, and gone home to watch House on her Tivo. Give it up and quit holding up the bus.
Who needs Ghost, we did it using a picoBSD boot floppy that dd-ed an image of the partition table and system partition onto the raw hard disk over ... damn, I forget whether we used nfs or ssh or http now... and then ran setsid after first boot.
Don't know if newsid was out yet.
Microsoft actually explicitly supports ghosting nowadays...
OK, add one word: this wouldn't be a way for Microsoft to discredit competing Ghosting?
I guess your Sharepoint isn't using all the "features" of ours. I can't edit shared documents or even use all the pulldown options on documents unless I'm using IE.
I'm pretty sure that our internal websites are almost 100% IE, but that's because using Sharepoint in anything but IE is a world of hurt.
Not that using Sharepoint from IE is exactly pleasant, but damn.
Given that it will undoubtedly be necessary to NewSID machines after all, who's got a copy of NewSID?
And, um, you know... this wouldn't be a way for Microsoft to discredit Ghosting?
"One thing that really impacts the crew's day-to-day operations is if the file server itself fails. This forces them to reload the hard drive and re-establish all the network drives and all the apps. They actually have to get out the media and load the image to the hard drive. That's a significant hit for the crew because we can't do everything for them from the ground.
Jesus Christ, given the cost per minute keeping those guys up there, I'd think they'd at the very least have redundant servers with redundant media.
Actually, I agree. I don't like Apple's hardware and I really want to run OS X on a Thinkpad. But I don't want to run Windows on one.
I have a Windows box at home, for the few programs (mostly games) I can't run on OS X. I call it my "wintendo". Don't sue me.
The simple fact is - that if the source ain't open then the 'standards' can't be open.
Yes, you can have open standards implemented with closed source. TCP/IP, for example, was a closed source open standard before KA9Q and others implemented their own versions.
An open standard, however, can't be defined by a closed source implementation (eg, OOXML), and an open standard can't require licenses for documentation or distribution. And it's the latter that this particular change is aimed at... letting European standards bodies that make money from licensing standards play in the sandpit along with kids who really DO share well with others.
Actually some of them work with Snow Leopard almost right out of the box.
"almost"
And audio on Linux is "almost" painless these days, isn't it?
Apple's target market aren't going to put up with "almost". I've gotten tired of dealing with "almost" myself.
Apple's target market aren't going to put up with the kinds of shenanigans it takes to get a hackintosh running, whether or not they pull this kind of stuff.
I gave up on speech recognition software after I got an iPaq with Dragon's command recognition software bundled.
The only command I could get it to reliably understand, and I kid you not, was the command to turn it off.
Virtualization doesn't change the legal requirement that you have a separate license for each instance of a virtual machine you create. This has nothing to do with copying in RAM... your VM instance has a separate copy on disk as well.
It would have cost too much to do it with slaves. They're not cheap.