Someone will surely have to upgrade to this in the course of their job. I have no doubt that their are SCO users who don't particularly like the company but have legacy apps that they are locked into.
What is needed is for a SCO upgrade customer to ask for the source code to Samba, GCC, MySQL and whatever other (L)/GPL code is in their OS. If they refuse or even worse get snarky with those contracts that you use against people then feed their Nazgul pecked rear ends to MySQL AB and the FSF.
As others have said, I don't bother blocking Google's ads. Quite a few other people don't either. They are relatively unobtrusive and most importantly don't:
BLINK AT ME FLASH AT ME PLAY FART NOISES AT ME SPAWN POPUPS FROM THE EGGCASE OF HELL MARCH ACROSS MY SCREEN LIKE THE WEHRMACHT DIDDLE BROWSER CONTROLS STEAL WINDOW FOCUS TRACK MY EVERY MOVE INSTALL MALWARE
Whew! I had to get that off my chest. If your "KICKASS" site will be using ads more in line with Google's then you'll be fine. If the ads in question are to be an assault on the senses or innocent webclients then your site isn't so "KICKASS" after all. Ultra obnoxious advertising is enough all by itself to make an otherwise nice site something to be utterly ignored. I'll also point out that my brain is equipped with quite the adblocker as well. And no DoubleClick, you aren't allowed to install implants to circumvent it.
OOO files are gzipped XML. AFAIK MS Word does not compress the files it is saving. Also, OOO will strip Word's undo history when importing which also tends to cut down on the file size.
I have an Epson scanner that I got working on OS X. Epson doesn't support it. There are some shareware proprietary drivers that cost $20 bucks or something . Maybe they work but I don't know. It turns out that the SANE port to OS X supports it pretty well with some tweaking.
sarcasm mode on: Oh dear, I had to do some tweaking to get something working in OS X. That makes it useless so I'll have to loudly and publically switch to something else. sarcasm mode off.
PS. That isn't the only time I've had to do tweaking to get OS X to behave the way I want it too. "Tweaking" is sometimes required on any environment. This isn't news. Oh, and I think Xscreensaver will somehow survice without the great Jamie Zawiniski.
Hopefully they will age the characters where Bart is a no job stoner who lives in the basement, Lisa gets married to a computer nerd and Maggie is a high school slut.
Well, it's comforting to know that Maggie's oral fixation will be intact. squitch-squitch.
1. Mysterious Creature is terrorizing the town/amusement park/mansion residents/...... 2. Mystery Machine rolls into town. 3. Creature encounters Mystery Machine Crew. 4. Shaggy and Scooby run away and hide in the kitchen/walk in freezer/.... 5. Thelma notices something strange. 6. Daphne and Fred say inane things and Fred tries to play Strong Leader. 7. Shaggy and Scooby happily raid fridge until rousted by Creature.
8. Thelma notices more clues. Fred plays Captain Obvious. 9. Creature terrorizes Shaggy and Scooby some more.
10. Thelma figures the whole thing out. Fred or Daphnie unmask Creature who turns out to be a minor character we met at the beginning of the episode. It was all a plot to scare everyone away from the town/amusement park/mansion residents/...... so he/she could have it for his/her own greedy scheme.
11. "And I would have gotten away with it if it wasn't for you meddling kids."
It isn't that MS will work to keep Windows off this hardware. It's just that for all the CPU is x86, it will still be a Mac. That means OpenFirmware rather than BIOS, runs on Hypertransport, and will have an "interesting" chipset from Window's point of view.
VPC is one thing but it will take some porting work to boot Windows as the host OS on these things. I think MS would do just that and cajole people to "upgrade" to Windows rather than the latest version of MacOS as more and more people own these things. Once Windows is in charge of one these from the git-go, it won't take much for the next purchase to be a Dell or whatever.
What would stop MS from getting Windows in a state where it can boot on this hardware? This isn't something MS would spring on us immediately. They'd wait until x86 Apple hardware is all over the place then proceed to knife the crap out of Apple's baby.
A big downer of running Linux on a Mac is missing things like full featured java, flash, wine, nvidia drivers, and few other binary tools. Not that this bothers the purists mind you but some of us have to use them.
Linux on one of these x86 Macs should run just as well as Linux on decent x86 chipsets.
Myself, I don't buy new Macs just to run Linux on them but I'll cheerfully deploy spare Macs as servers if they're somewhat beefy.
I thought that the x86 is register starved compared to the PPC which is why PPC hosts can emulate x86 with tolerable speed but not vice versa. Furthermore, isn't true that x86-64 only partially alleviates this? We've already seen further processor speed increases leveling out. We can't count on future superfast future x86-64 chips to emulate say a 2 GHZ PPC well enough to deliver an acceptable experience.
I'm with some of the other posters. I never thought Apple would do anything this crazy.
Perhaps the Mac crowd will become the ultimate DRM apologists, claiming, with some credibility, that Mac couldn't survive if it didn't have TC/DRM involved.
Prior to iTunes and the iTunes store, almost every poster here agreed that DRM is pure dag nasty evil period, end of story, will boycott any vendor, etc. Once a few of us toked on the iTunes crack pipe, DRM suddenly became okay for quite a few people here. "Oooooooooohh shiney!". "This is reasonable DRM.... Don't beat up on Apple or the DRM will get even worse...." etc. etc. ad nauseatingly.
It all goes to show that the Reality Distortion Field is working just peachy. You're probably correct that we are about to see a lot more Apple inspired DRM apologists.
Using DRM for such is largely unnecessary anyway. Look at how long it takes for Linux and the BSDs to get drivers sometimes. Apple is only going to support their chipsets and will probably go after anyone who starts running "Darwin Driver" projects that let OS X out of the Apple cage.
Suppose the trusted machine is the bitch of a normal computer? The worst case scenerio is analog video and audio grabs with the trusted machine forced into serving as a proxy for the normal one; I rather like the idea of a transparent bridge setup in which the normal machine has final say over all comms. Still, if they want us to treat the nasty things as black boxes then let's treat them as black boxes with a shotgun stuck in their mouths.
Quite a bit of the comments in Webcore say things like "This change addresses issue xqb967." or some such. Basically, Apple's changes to khtml don't make much sense outside of Apple's source control system. You cannot simply drop such into another project. By the time you reason out whatever xqb967 is, you may as well have redeveloped the code yourself.
None of this is utterly terrible. Webcore can be used in isolation. khtml can be used in isolation. Adding beneficial features from Webcore isn't trivial. A good bit of the time, it is actually simpler to redevelop the features. The khtml devs aren't complaining (much) about this.
They ARE complaining about being hammered by clueless fanbois whenever Webcore has a feature that khtml lacks. Webcore is a two year old fork of khtml that isn't well documented outside of it's parent source control system. This is what is meant by "bare minimum". This "bare minimum" situation is tolerable. Take it as read I repeated the previous sentence 10,000 times in addition to the other emphasis. This has far more to do bad end-user behavior than Apple. This bad end-user behavior is caused by a perception of co-operation that never existed.
It is the behavior of a vocal contingent of end-users that is intolerable. Apple's behavior merely rankles slightly compared to that of the fanbois. Sometimes the khtml guys can make limited use of Webcore code. As time passes this will be even less possible than the current breakthrough.
The khtml devs do not deserve abuse for feature disparity vis-a-vis Webcore. This is the point I'm making. Apple's behavior is nearly irrelavent and only constitutes cause for irritation at most.
When you've been falsely accused of a crime or illegal tactics are used against you, you'll gain a new appreciation for lawyers.
Lawyers are used to carry out both activities. The fact that one has to spend exorbitant amounts of money on their own lawyers to fight it off is reason enough to have contempt for both lawyers and the system.
Going forward this is going to be less and less possible yet the khtml team will continue to get grief whenever there is feature disparity. If Webcore is so fantabulus then perhaps the fanbois should just use it and leave the khtml people alone. They do have other design goals to attend to such as KDE integration. Slavishly attending to everything Apple does as though it were the most important thing in the world will not leave time for other priorities.
All this stuff about "Apple did this and the khtml guys did that" is utterly irrelavent to the point I and the khtml devs were trying to make.
The khtml devs beef is with fanbois who think that khtml should have new Webcore features an hour or two after Webcore gets them. When the khtml people try to explain why matters are bit more difficult than that then the fanbois throw around terms like "lazy", "unresponsive", and "kick in the pants".
Apple's behaivor has zero to do with the point I was trying to make.
There is no problem with forking. There is a problem with loudmouth fanbois who think that presto chango re-arrango that features of one fork can be readily dropped into another. Even worse are fanbois who are insulting and use phrases like "lazy" and "kick in the pants".
The bulk of the khtml devs' vitriol has been directed at fanbois and rightfully so. As one ktml dev said of Apple's conduct "and that is their right".
"Allan Sandfeld Jensen announced today that Konqueror passes the Acid2 test too. Half of the patches could be merged from Apple's Webcore, the rest needed to be rewritten from scratch.""
It's amazing what people can do when sufficiently motivated.
THIS sort of thing is EXACTLY what the khtml devs were complaining about. Yes, Apple does the bare minimum the LGPL requires with Webcore but the khtml devs accepted that.
The point these guys have been trying to get across over and over and over and over (repeat several thousand times for the extra dense) is that when Webcore can do something that khtml cannot IT IS NOT LAZINESS ON THE PART OF THE KHTML DEVELOPERS. WEBCORE CODE CANNOT JUST BE DROPPED INTO THE KHTML TREE. Webcore directly uses OS X features. That is one problem. The code bombs Apple drops periodically have inadequate documentation as to why some changes were made and not others.
Webcore at this point is a khtml fork that is about two years old. The khtml devs might as well be asked to merge Gecko code for all of the similarity they have at this point.
Slashdot Mirror
Someone will surely have to upgrade to this in the course of their job. I have no doubt that their are SCO users who don't particularly like the company but have legacy apps that they are locked into.
What is needed is for a SCO upgrade customer to ask for the source code to Samba, GCC, MySQL and whatever other (L)/GPL code is in their OS. If they refuse or even worse get snarky with those contracts that you use against people then feed their Nazgul pecked rear ends to MySQL AB and the FSF.
As others have said, I don't bother blocking Google's ads. Quite a few other people don't either. They are relatively unobtrusive and most importantly don't:
BLINK AT ME
FLASH AT ME
PLAY FART NOISES AT ME
SPAWN POPUPS FROM THE EGGCASE OF HELL
MARCH ACROSS MY SCREEN LIKE THE WEHRMACHT
DIDDLE BROWSER CONTROLS
STEAL WINDOW FOCUS
TRACK MY EVERY MOVE
INSTALL MALWARE
Whew! I had to get that off my chest. If your "KICKASS" site will be using ads more in line with Google's then you'll be fine. If the ads in question are to be an assault on the senses or innocent webclients then your site isn't so "KICKASS" after all. Ultra obnoxious advertising is enough all by itself to make an otherwise nice site something to be utterly ignored. I'll also point out that my brain is equipped with quite the adblocker as well. And no DoubleClick, you aren't allowed to install implants to circumvent it.
You didn't read my post carefully either:
"Also, OOO will strip Word's undo history when importing which also tends to cut down on the file size."
OOO files are gzipped XML. AFAIK MS Word does not compress the files it is saving. Also, OOO will strip Word's undo history when importing which also tends to cut down on the file size.
I have an Epson scanner that I got working on OS X. Epson doesn't support it. There are some shareware proprietary drivers that cost $20 bucks or something . Maybe they work but I don't know. It turns out that the SANE port to OS X supports it pretty well with some tweaking.
sarcasm mode on: Oh dear, I had to do some tweaking to get something working in OS X. That makes it useless so I'll have to loudly and publically switch to something else.
sarcasm mode off.
PS. That isn't the only time I've had to do tweaking to get OS X to behave the way I want it too. "Tweaking" is sometimes required on any environment. This isn't news. Oh, and I think Xscreensaver will somehow survice without the great Jamie Zawiniski.
I like the professor
He always saves their butts
He could build a nuclear reactor
From a couple of coconuts
She said, "That guy's a genius"
I shook my head and laughed
I said, "If he's so fly, then tell me why
He couldn't build a lousy raft"
"Weird Al" Yankovic
Isle Thing
(Parody of "Wild Thing")
Hopefully they will age the characters where Bart is a no job stoner who lives in the basement, Lisa gets married to a computer nerd and Maggie is a high school slut.
Well, it's comforting to know that Maggie's oral fixation will be intact. squitch-squitch.
If Teddy Ruxpin boarhogs some Ewoks then I'll gladly pay to see it.
1. Mysterious Creature is terrorizing the town/amusement park/mansion residents/......
2. Mystery Machine rolls into town.
3. Creature encounters Mystery Machine Crew.
4. Shaggy and Scooby run away and hide in the kitchen/walk in freezer/....
5. Thelma notices something strange.
6. Daphne and Fred say inane things and Fred tries to play Strong Leader.
7. Shaggy and Scooby happily raid fridge until rousted by Creature.
8. Thelma notices more clues. Fred plays Captain Obvious.
9. Creature terrorizes Shaggy and Scooby some more.
10. Thelma figures the whole thing out. Fred or Daphnie unmask Creature who turns out to be a minor character we met at the beginning of the episode. It was all a plot to scare everyone away from the town/amusement park/mansion residents/......
so he/she could have it for his/her own greedy scheme.
11. "And I would have gotten away with it if it wasn't for you meddling kids."
It isn't that MS will work to keep Windows off this hardware. It's just that for all the CPU is x86, it will still be a Mac. That means OpenFirmware rather than BIOS, runs on Hypertransport, and will have an "interesting" chipset from Window's point of view.
VPC is one thing but it will take some porting work to boot Windows as the host OS on these things. I think MS would do just that and cajole people to "upgrade" to Windows rather than the latest version of MacOS as more and more people own these things. Once Windows is in charge of one these from the git-go, it won't take much for the next purchase to be a Dell or whatever.
What would stop MS from getting Windows in a state where it can boot on this hardware? This isn't something MS would spring on us immediately. They'd wait until x86 Apple hardware is all over the place then proceed to knife the crap out of Apple's baby.
I jumped through the hoops to get that IBM JDK. It is almost full featured. The browser plug-in wasn't built for some reason.
A big downer of running Linux on a Mac is missing things like full featured java, flash, wine, nvidia drivers, and few other binary tools. Not that this bothers the purists mind you but some of us have to use them.
Linux on one of these x86 Macs should run just as well as Linux on decent x86 chipsets.
Myself, I don't buy new Macs just to run Linux on them but I'll cheerfully deploy spare Macs as servers if they're somewhat beefy.
I thought that the x86 is register starved compared to the PPC which is why PPC hosts can emulate x86 with tolerable speed but not vice versa. Furthermore, isn't true that x86-64 only partially alleviates this? We've already seen further processor speed increases leveling out. We can't count on future superfast future x86-64 chips to emulate say a 2 GHZ PPC well enough to deliver an acceptable experience.
I'm with some of the other posters. I never thought Apple would do anything this crazy.
Perhaps the Mac crowd will become the ultimate DRM apologists, claiming, with some credibility, that Mac couldn't survive if it didn't have TC/DRM involved.
Prior to iTunes and the iTunes store, almost every poster here agreed that DRM is pure dag nasty evil period, end of story, will boycott any vendor, etc. Once a few of us toked on the iTunes crack pipe, DRM suddenly became okay for quite a few people here. "Oooooooooohh shiney!". "This is reasonable DRM.... Don't beat up on Apple or the DRM will get even worse...." etc. etc. ad nauseatingly.
It all goes to show that the Reality Distortion Field is working just peachy. You're probably correct that we are about to see a lot more Apple inspired DRM apologists.
Using DRM for such is largely unnecessary anyway. Look at how long it takes for Linux and the BSDs to get drivers sometimes. Apple is only going to support their chipsets and will probably go after anyone who starts running "Darwin Driver" projects that let OS X out of the Apple cage.
Suppose the trusted machine is the bitch of a normal computer? The worst case scenerio is analog video and audio grabs with the trusted machine forced into serving as a proxy for the normal one; I rather like the idea of a transparent bridge setup in which the normal machine has final say over all comms. Still, if they want us to treat the nasty things as black boxes then let's treat them as black boxes with a shotgun stuck in their mouths.
So, what's a fanbois? I'm assuming that's french?
Just like a fanboy but with even more "parent's basementness" about it.
There is a project to serve NTP round-robin from a number of servers. You can use this pool thusly with ntpd:
server pool.ntp.org
If you live in Canada or the US you can even do:
server north-america.pool.ntp.org
Read more at:
http://www.pool.ntp.org/
Quite a bit of the comments in Webcore say things like "This change addresses issue xqb967." or some such. Basically, Apple's changes to khtml don't make much sense outside of Apple's source control system. You cannot simply drop such into another project. By the time you reason out whatever xqb967 is, you may as well have redeveloped the code yourself.
None of this is utterly terrible. Webcore can be used in isolation. khtml can be used in isolation. Adding beneficial features from Webcore isn't trivial. A good bit of the time, it is actually simpler to redevelop the features. The khtml devs aren't complaining (much) about this.
They ARE complaining about being hammered by clueless fanbois whenever Webcore has a feature that khtml lacks. Webcore is a two year old fork of khtml that isn't well documented outside of it's parent source control system. This is what is meant by "bare minimum". This "bare minimum" situation is tolerable. Take it as read I repeated the previous sentence 10,000 times in addition to the other emphasis. This has far more to do bad end-user behavior than Apple. This bad end-user behavior is caused by a perception of co-operation that never existed.
It is the behavior of a vocal contingent of end-users that is intolerable. Apple's behavior merely rankles slightly compared to that of the fanbois. Sometimes the khtml guys can make limited use of Webcore code. As time passes this will be even less possible than the current breakthrough.
The khtml devs do not deserve abuse for feature disparity vis-a-vis Webcore. This is the point I'm making. Apple's behavior is nearly irrelavent and only constitutes cause for irritation at most.
When you've been falsely accused of a crime or illegal tactics are used against you, you'll gain a new appreciation for lawyers.
Lawyers are used to carry out both activities. The fact that one has to spend exorbitant amounts of money on their own lawyers to fight it off is reason enough to have contempt for both lawyers and the system.
Going forward this is going to be less and less possible yet the khtml team will continue to get grief whenever there is feature disparity. If Webcore is so fantabulus then perhaps the fanbois should just use it and leave the khtml people alone. They do have other design goals to attend to such as KDE integration. Slavishly attending to everything Apple does as though it were the most important thing in the world will not leave time for other priorities.
All this stuff about "Apple did this and the khtml guys did that" is utterly irrelavent to the point I and the khtml devs were trying to make.
The khtml devs beef is with fanbois who think that khtml should have new Webcore features an hour or two after Webcore gets them. When the khtml people try to explain why matters are bit more difficult than that then the fanbois throw around terms like "lazy", "unresponsive", and "kick in the pants".
Apple's behaivor has zero to do with the point I was trying to make.
And the problem with forking is.... what exactly?
There is no problem with forking. There is a problem with loudmouth fanbois who think that presto chango re-arrango that features of one fork can be readily dropped into another. Even worse are fanbois who are insulting and use phrases like "lazy" and "kick in the pants".
The bulk of the khtml devs' vitriol has been directed at fanbois and rightfully so. As one ktml dev said of Apple's conduct "and that is their right".
"Allan Sandfeld Jensen announced today that Konqueror passes the Acid2 test too. Half of the patches could be merged from Apple's Webcore, the rest needed to be rewritten from scratch.""
It's amazing what people can do when sufficiently motivated.
THIS sort of thing is EXACTLY what the khtml devs were complaining about. Yes, Apple does the bare minimum the LGPL requires with Webcore but the khtml devs accepted that.
The point these guys have been trying to get across over and over and over and over (repeat several thousand times for the extra dense) is that when Webcore can do something that khtml cannot IT IS NOT LAZINESS ON THE PART OF THE KHTML DEVELOPERS. WEBCORE CODE CANNOT JUST BE DROPPED INTO THE KHTML TREE. Webcore directly uses OS X features. That is one problem. The code bombs Apple drops periodically have inadequate documentation as to why some changes were made and not others.
Webcore at this point is a khtml fork that is about two years old. The khtml devs might as well be asked to merge Gecko code for all of the similarity they have at this point.
Journalists will use it to work up stories without having to leave their offices. The only thing we need now is a piece of fairy cake.