Are you sure you mean Photoshop CS, not Photoshop Album? Photoshop CS is Adobe's flagship product, and a *serious* image editor. 16bpp, L*A*B, CMYK, ICC color management, oodles of awesome filters, the works.
Photoshop Album is their cut down "consumer" variant, and rather more likely to be what you meant.
We have several advantages now. First, we have the hindsight of what happened to UNIX, and a general understanding that it was bad for everybody involved.
Second, the licensing is crucially different. Linux is more amenible to standards because of its licensing - vendor extensions like those that killed UNIX can't be kept proprietary.
Additionally, there is a culture of co-operation among Linux vendors and developers. That's really important. For example, one of the Scribus developers works regularly with all the major distributions to help standardise and improve issues of importance to Scribus (less patched-and-hacked versions of Qt, bring GhostScript out of the stone age, etc). Basically all the major vendors contribute to and co-operate on core toolkit and kernel work. It's not perfect, but it's a heck of a lot better than it was for proprietary UNIX.
With these advantages, I doubt the fragmentation will ever get too bad. The frustrations and maintainance costs of fragmentation its self will become a force to bring everything more into line. For the commercial vendors, customer pressure and pressure from ISVs will help too.
I think life is easier now for an application developer than it was a while ago. The major toolkits have quite stable APIs and even maintain a stable ABI unless built with dumb compiler options. gcc's ABI & API stability is improving constantly, and is already pretty much there for C code. RPM is widely supported, required by the LSB, and where it's not the native format users know how to handle that ('alien' and friends).
Things could suck a lot less. Easy ways to discover installed libraries and versions. A F***ING STANDARD WAY TO FIND OUT WHAT DISTRO YOU'RE RUNNING ON. More careful co-ordination of build options and compiler options for key toolkits and libraries to improve ABI compatibility across distros. There's lots more, too. Overall, though, I don't think it's too bad.
Perfect compatibility just won't happen. There will always be people who want to do things differently. That's fine, but they have to realise they will sacrifice compatibility. If their work produces good ideas, others can integrate those ideas so they can be relied on by everybody. A binary LSB distribution that can just be dropped in place on any distro would make a big difference, though.
Apple had to take a drastic step because MacOS 9 had reached the end of the line. It couldn't use the protected memory facilities in the PPC CPUs that had been standard since OS 7.5.5 or so, had apalling virtual memory, and was generally a serious mess.
Linux has the advantage of building on the design of UNIX - the core of which has proved extremely future proof. It's able to support modern hardware capabilities and software needs without total and drastic rewrites requiring emulation layers, etc. It's also maintainable, which MacOS 9 had clearly ceased to be.
The Linux kernel still runs happily in ~2MB of RAM. There are bloat issues, but they're with the application stack on top of the kernel.
I'd also like to point out that MacOS/X is excruciating to use with anything less than a 400MHz G4 with 256MB of RAM, and feels pretty unimpressive even on a 1GHz G4 with 512MB of RAM. MacOS/X fixed many things, but bloat was not one of them.
Unfortunately I no longer have the calculations. There were really only hard calculations for the initial outlay, quite frankly. IIRC the LTSP deployment cost us about 1/4 as much as the equivalent Citrix deployment, and 1/2 as much as 2k3TS or XP desktops, including hardware and software licensing costs.
Initial deployment size was only 10 users in a business of 30. It's not likely to expand until/if OpenOffice stops sucking so we can have more demanding users use the system without a mass exodus of staff;-) . Note that at a deployment this size, issues of base license costs, server costs, etc really start to matter.
The LTSP deployment costs were pushed up by the fact that the server bought for that was massively overpowered for the job. We needed a storage server and decided it was safe to double up the roles (a decision that's worked extremely well). The other deployment options would've required us to buy a separate storage server - Windows file servers are not an attractive option in our environment, and Windows isn't good at multi-role servers.
The primary "running" costs on the old systems were admin time (minimal, I spend all my time fixing F**ing macs) and lost staff time due to painfully, excruciatingly slow systems.
It didn't seem possible to reliably estimate the administration time costs or staff time costs/savings of any of the new systems without test deployments, which we're just not equipped for when it comes to commercial software. We can't just buy a win2k3 server and citrix "to see how it works on a test group." The best I could do was trial LTSP, which I could deploy on existing hardware (including server) and test with a couple of the users. It took some work getting over the hiccups but worked very well after that. For Citrix, RDP, and WinXP desktops I had to rely mostly on the experience of other network admins I know in larger organisations.
Looking back at it now, the LTSP setup probably costs us as less than the others were likely to, but probably didn't beat 2k3TS or XP desktops by a huge margin. There's a lot of screwing around due to crappy/absent user management tools, and while the software the users use is generally very reliable, there *are* a few niggling bugs that are a real pain. Bug fixing is not cheap. Windows has the user management stuff down really well, and the pain of desktops can be reduced by careful use of system imaging, domains, group policy, etc (but that would've taken a lot of learning).
On the flip side, day to day management is no worse than or slightly better than the old systems. User management is much the same, but adding and removing hosts is now utterly trivial, which helps. I understand that user management is one area the Windows networks definitely have going for them.
ROI can be considered mainly in terms of how the deployment affects users work and how it affects demands on my time.
Demands on my time are largely unchanged, when they were growing with the old system (ancient mail clients, ancient overloaded systems, etc). The staff are able to do more and get it done more quickly and easily using the very simple and cut down interface they're provided with, and it works very well.
Without a time machine I can't find out what our ROI would've been on the other solutions. How long would I have spent learning Windows administration and user management, learning and configuring Citrix, etc? How much more would backing up and maintaining yet another server have cost us? How much time would I have saved with the user management tools? Would I have had lots of trouble getting our ancient terminal-based accounts & bookings system working from Windows? The list goes on.
Overall, I think that my UNIX/Linux experience was a large part of why our choice worked, and why it was better than the alternatives for us. An experienced Citrix/TS admin or windows domain admin would probably have been better off going in the other direction. After all, admin time is the majority of the ongoing costs in our environment.
A lot of people don't seem to understand that the initial layout - buying machines and software - is almost always the *cheapest* part if IT infrastructure, particularly when you're talking about user desktops.
I agree that that's often, even usually, true. However, I'm not sure if the massive cost increase of Citrix is worth the managment benfits on some scales of network.
I don't think I said anything about that being all Citrix had going for it. I know it's very capable.
It's also *very* expensive, and when I looked at using Citrix for thin clients it turned out it would've been cheaper deploy desktops and we would've had a lot of change out of that. For 10,000 desktops I imageine the management benefits and other facilities bring you real savings. For 30, like I have, or the OP's 100, it's just not worth the outlay IMO.
Since not even the basic Terminal Server turned out to be especially useful for us once CALs were factored in, I think Citrix would've been nuking a fly (and those nukes are pricey things).
I've been using thin clients at work for a while (LTSP based - netbooted X11 thin clients). They work very well, and I'm fairly happy with the results (some of the software could be less buggy, but that's OSS for you). They're delightfully easy to manage, in that they require essentially none. Unfortunately the server side configuration tools for user's desktop environments and apps are almost non-existent so you'll have to do a lot more rolling-your-own than you'd probably like.
Unfortunately, I'm having real troubles with the vertical market vendors as we seek a new newspaper accounts & bookings system. They *all* require Windows desktops - many don't even work with TS / Citrix. Consider this factor VERY carefully before deciding on a thin client roll out, especially Linux thin clients.
How well it works will depend a lot on how much in-house development you do... and in-house development is *expensive* (in time, if nothing else) to a small/medium business.
I share your opinion on TS and CALs. I don't see the point - the CALs negate most of the lower outlay of thin clients. Citrix makes it even worse. Unless you expect to save a *lot* on management and running costs, I don't see how it's worth it.
I work regularly on a real SMP system, I and consequently I've been drooling for dual core since I first heard the x86 CPU vendors were (finally) getting around to adding it.
SMP makes a massive difference on a system - if your workloads benefit. Mine do - I spend a lot of time compiling things, and the compiling (on the right codebase) tends to scale in an almost linear way with number of CPUs. Not only does SMP make this vastly faster, but it leaves your system so much more responsive that it's hard to believe.
Even if dual core CPUs have only half the benefits (I imagine the Intel ones will, given their memory bandwidth needs) I'd still be really tempted. The power consumption is a nasty issue though.
Good point. They'd have to work from a pre-generated finite set of keys, since otherwise old discs wouldn't play on new players (the disc wouldn't have a suitable symmetric key encrypted with the player key, since the player key didn't exist at the time) but it should work unless someone "in the know" leaks the whole keyspace or something.
It would certainly make life harder on the attacker, since a design issue that permitted older models to be cracked could be rectified and a new key assigned without sacrificing backward compatibility with older discs.
Personally, I wish they'd just give up and go away. I'll just stop buying films entirely if I can't watch them in peace, and it's already getting close to that point already. Only open source DVD players and DVD player hacks that introduce a certain disrespect for skip blocking etc are keeping me interested as it is.
That seems reasonable, though I think it very unlikely that players could be updated from the 'net with new keys. Keys over the 'net just smells like a key-stealing party, plus most players will be set-top and not exactly convenient to an Internet connection.
My personal suspicion is that if the hardware's protection is broken once to get one key, the other 99 are probably also toast. I guess it depends on the type of break and how expensive it is (time + money).
"... with the compromised set of keys..." is the key phrase. A given model, if this is the same as CSS, has a CSS key - not a given unit of that model. Revoking the key would revoke it for all units of that model since they all have the same key.
Nasty. DVD is offensive enough already ("You may not skip this!"), this will just make it worse. Argh.
With most such set-ups your Internet connection is generally not totally blocked, just severely restricted. Any web request gets proxy-redirected to a page with instructions on how to clean your machine up, and download links from the ISPs local mirrors. Anything else is locked down.
I don't know if this is what bigpond are doing, but that's the usual way to handle this and it seems to work extremely well. My ISP uses a similar trick when users go over quota.
Actually, with many such set-ups the user opens their web browser and gets proxy-redirected to a page explaining what they need to do to fix their computer, complete with download links and moron-proof instructions. An email appears in their mailbox explaining the same thing, and everything else is firewalled off at the router.
Ditto. In both senses - that is, been there done that, and "use the program `ditto' to do it".
`ditto' is the program the Mac developers wrote instead of tweaking all the UNIX utilities to work with their dual-forked filesystem. Never, ever, ever use `cp' on MacOS/X - only `ditto'.
The only people OS X will not satisfy are RMS-style free software zealots, and those who want complete tweakability and control (which is perfectly valid). For everyone else who wants a UNIX workhorse that is stable, has full driver support, has "It Just Works" down pat, and wants to get work done, OS X is peerless.
I'm not satisfied by OS/X, and I'm no free software zealot. I don't want complete tweakability and control (KDE drives me nuts for that reason) either, though I do want some minimal control - turn off all the godamm "eye candy", mostly.
I'm not satisfied with it because I need a UNIX platform for most of my work, and MacOS/X is not UNIX. It has a UNIX/BSD compatible subsystem, but uses a different binary format, "interesting" linker arguments, has different shared library handling, and has a relatively poorly integrated X11 environment (X11 its self works great, but launching apps etc is PITA) that isn't installed by default. It's UNIX-compatible enough that apps need little porting to run under X11, but it ain't UNIX.
My solution to this is very simple - don't buy Apple hardware. I don't see the point in buying an Apple machine only to try to kludge Linux onto it - it'll never work particularly great (Apple aren't big on open sourcing drivers or releasing specs) and it'll cost more for the power you get.
So... I'm with you on that. Why do this? Just buy an x86 box and drop Linux or a *BSD on it if you want UNIX.
I can agree with you on some points, but as a long-time UNIX _and_ Linux user and more recent MacOS/X user, not all.
2: X11 doesn't come pre-installed, it has to be custom-installed by the user though it is shipped with the OS. A most unfortunate decision in my book.
5: Doing this largely denies you access to the system admin tools etc. It also means you still have the non-trivial overhead of Aqua, the Finder, etc.
More importantly, it doesn't change the fact that you're running on an OS with several fundamentally different ideas of what an "application" is ("native" Aqua, X11, console, Java, etc).
It also has a different binary format (Mach-O), a strange linker (-framework anybody? Why didn't they at least make it -framework,name,name like the rest?!?), and other differences that make it hard to treat it as a generic *nix.
Oh yeah, and Apple X11 seems really slow compared to the versions I use on other platforms, which doesn't help. OTOH, perhaps that's because I use it on an eMac.
6: Would be more true if (a) you could launch X11 apps from the file manager and dock as easily as.pkg-based Aqua ones, without using AppleScript hacks, and (b) X11 apps could get their own dock entries etc. As I work on porting to MacOS/X, I'm increasingly learning that neither of these would be excessively hard for Apple to do. I just don't think they want to.
Now, for most users, who cares. They're happy with OS/X. If you're looking for, say, a PPC UNIX devel machine, though, this sort of thing makes sense. I still think it's utter BS for the proposed use - cheap desktops.
I'm not sure it makes sense as a "cheap computer" approach. I'd argue that it's hardly pointless, though:
(a) Some folks like mac hardware but can't stand MacOS/X . I'm not one of them, but I prefer using a more "true" UNIX with a single, consistent API and with well-integrated X11.
(b) Other folks are developing PowerPC applications for UNIX. Linux, being much more "unix-y" than MacOS/X, will be a much better fit for that sort of role.
Yes, I know Apple says OS/X is UNIX. Well... it has a UNIX/BSD subsystem, but it sure ain't UNIX. I found that one out first hand as I helped port Scribus to it (still in progress). Mach-O, Aqua, Carbon, Cocoa, weird font formats, weird FS layout, etc. Not bad, but not UNIX.
One possible reason is to give them room to move in the market. They can now, if this article reflects the general nature of these CPUs, ramp their clock speeds in a hurry if they need to. In the mean time, they can keep slowly upping the speeds and keep the higest speed ones priced to the max.
I'm Australian. I don't even watch TV anymore because it's so filled with utter crap, because I can't stand the commercials, and because I see the few things I care about at friends places months and sometimes years before it hits TV here.
Pay for downloaded shows? At decent rates, with guaranteed quality and no stuffing around? HELL YES, even if it's a buck an episode or something (adds up compared to renting the DVD later). <i>But only if there are no ads.</i> They grate on my so badly I just can't stand watching TV now, and that wouldn't change with downloaded episodes.
I'd like to think the service would not be DRM'd up the wazoo (given that the episodes can be obtained easily enough with bittorrent etc anyway, so it's not like they'd actually be protecting anything much), but I doubt we'd be that lucky.
As I alluded to when responding to another response to my post, I'm aware that's a factor. It's not, however, what pays the bills in the short/medium term.
I also tend to view the situation with "creative" apps as quite different to with OSes. It's much easier to just use whatever Linux distro is currently in vogue and looks attractive for your needs; they just don't take that much distro-specific learning. The same is not true of desktop publishing or high-end web authoring packages.
Because of this, I don't think mind share is really that big a deal with Linux distros. The chances are the PHBs will make the distro selection anyway, and they'll probabably just pick the most familar sounding name / the lowest price / the one that offers them the best kickback on the deal.
Well, there's is arguably the indirect "mind share" effect - but that's about it, really. That's also a very long term thing, and the context of this article really isn't about long term.
Thus, perhaps you'd like to expound upon your reasoning behind your accusation of my ignorance? Otherwise you're at risk of showing your own arrogance and inability to communicate a point instead of simply sniping - and you wouldn't want that.
I freely admit I'm in many ways ignorant, but I don't see how this has anything to do with any of them.
Slashdot Mirror
... support the full features of PDF, such as ICC colour management, PDF 1.4 transparency, etc etc etc .
Preview is nice and all, but far from a perfect PDF viewer. It cuts a lot of corners.
You're quite right, it was Photoshop Elements that I meant.
Whoops.
Are you sure you mean Photoshop CS, not Photoshop Album? Photoshop CS is Adobe's flagship product, and a *serious* image editor. 16bpp, L*A*B, CMYK, ICC color management, oodles of awesome filters, the works.
Photoshop Album is their cut down "consumer" variant, and rather more likely to be what you meant.
... but it doesn't have to for Linux.
We have several advantages now. First, we have the hindsight of what happened to UNIX, and a general understanding that it was bad for everybody involved.
Second, the licensing is crucially different. Linux is more amenible to standards because of its licensing - vendor extensions like those that killed UNIX can't be kept proprietary.
Additionally, there is a culture of co-operation among Linux vendors and developers. That's really important. For example, one of the Scribus developers works regularly with all the major distributions to help standardise and improve issues of importance to Scribus (less patched-and-hacked versions of Qt, bring GhostScript out of the stone age, etc). Basically all the major vendors contribute to and co-operate on core toolkit and kernel work. It's not perfect, but it's a heck of a lot better than it was for proprietary UNIX.
With these advantages, I doubt the fragmentation will ever get too bad. The frustrations and maintainance costs of fragmentation its self will become a force to bring everything more into line. For the commercial vendors, customer pressure and pressure from ISVs will help too.
I think life is easier now for an application developer than it was a while ago. The major toolkits have quite stable APIs and even maintain a stable ABI unless built with dumb compiler options. gcc's ABI & API stability is improving constantly, and is already pretty much there for C code. RPM is widely supported, required by the LSB, and where it's not the native format users know how to handle that ('alien' and friends).
Things could suck a lot less. Easy ways to discover installed libraries and versions. A F***ING STANDARD WAY TO FIND OUT WHAT DISTRO YOU'RE RUNNING ON. More careful co-ordination of build options and compiler options for key toolkits and libraries to improve ABI compatibility across distros. There's lots more, too. Overall, though, I don't think it's too bad.
Perfect compatibility just won't happen. There will always be people who want to do things differently. That's fine, but they have to realise they will sacrifice compatibility. If their work produces good ideas, others can integrate those ideas so they can be relied on by everybody. A binary LSB distribution that can just be dropped in place on any distro would make a big difference, though.
Apple had to take a drastic step because MacOS 9 had reached the end of the line. It couldn't use the protected memory facilities in the PPC CPUs that had been standard since OS 7.5.5 or so, had apalling virtual memory, and was generally a serious mess.
Linux has the advantage of building on the design of UNIX - the core of which has proved extremely future proof. It's able to support modern hardware capabilities and software needs without total and drastic rewrites requiring emulation layers, etc. It's also maintainable, which MacOS 9 had clearly ceased to be.
The Linux kernel still runs happily in ~2MB of RAM. There are bloat issues, but they're with the application stack on top of the kernel.
I'd also like to point out that MacOS/X is excruciating to use with anything less than a 400MHz G4 with 256MB of RAM, and feels pretty unimpressive even on a 1GHz G4 with 512MB of RAM. MacOS/X fixed many things, but bloat was not one of them.
Unfortunately I no longer have the calculations. There were really only hard calculations for the initial outlay, quite frankly. IIRC the LTSP deployment cost us about 1/4 as much as the equivalent Citrix deployment, and 1/2 as much as 2k3TS or XP desktops, including hardware and software licensing costs.
;-) . Note that at a deployment this size, issues of base license costs, server costs, etc really start to matter.
Initial deployment size was only 10 users in a business of 30. It's not likely to expand until/if OpenOffice stops sucking so we can have more demanding users use the system without a mass exodus of staff
The LTSP deployment costs were pushed up by the fact that the server bought for that was massively overpowered for the job. We needed a storage server and decided it was safe to double up the roles (a decision that's worked extremely well). The other deployment options would've required us to buy a separate storage server - Windows file servers are not an attractive option in our environment, and Windows isn't good at multi-role servers.
The primary "running" costs on the old systems were admin time (minimal, I spend all my time fixing F**ing macs) and lost staff time due to painfully, excruciatingly slow systems.
It didn't seem possible to reliably estimate the administration time costs or staff time costs/savings of any of the new systems without test deployments, which we're just not equipped for when it comes to commercial software. We can't just buy a win2k3 server and citrix "to see how it works on a test group." The best I could do was trial LTSP, which I could deploy on existing hardware (including server) and test with a couple of the users. It took some work getting over the hiccups but worked very well after that. For Citrix, RDP, and WinXP desktops I had to rely mostly on the experience of other network admins I know in larger organisations.
Looking back at it now, the LTSP setup probably costs us as less than the others were likely to, but probably didn't beat 2k3TS or XP desktops by a huge margin. There's a lot of screwing around due to crappy/absent user management tools, and while the software the users use is generally very reliable, there *are* a few niggling bugs that are a real pain. Bug fixing is not cheap. Windows has the user management stuff down really well, and the pain of desktops can be reduced by careful use of system imaging, domains, group policy, etc (but that would've taken a lot of learning).
On the flip side, day to day management is no worse than or slightly better than the old systems. User management is much the same, but adding and removing hosts is now utterly trivial, which helps. I understand that user management is one area the Windows networks definitely have going for them.
ROI can be considered mainly in terms of how the deployment affects users work and how it affects demands on my time.
Demands on my time are largely unchanged, when they were growing with the old system (ancient mail clients, ancient overloaded systems, etc). The staff are able to do more and get it done more quickly and easily using the very simple and cut down interface they're provided with, and it works very well.
Without a time machine I can't find out what our ROI would've been on the other solutions. How long would I have spent learning Windows administration and user management, learning and configuring Citrix, etc? How much more would backing up and maintaining yet another server have cost us? How much time would I have saved with the user management tools? Would I have had lots of trouble getting our ancient terminal-based accounts & bookings system working from Windows? The list goes on.
Overall, I think that my UNIX/Linux experience was a large part of why our choice worked, and why it was better than the alternatives for us. An experienced Citrix/TS admin or windows domain admin would probably have been better off going in the other direction. After all, admin time is the majority of the ongoing costs in our environment.
A lot of people don't seem to understand that the initial layout - buying machines and software - is almost always the *cheapest* part if IT infrastructure, particularly when you're talking about user desktops.
I agree that that's often, even usually, true. However, I'm not sure if the massive cost increase of Citrix is worth the managment benfits on some scales of network.
I don't think I said anything about that being all Citrix had going for it. I know it's very capable.
It's also *very* expensive, and when I looked at using Citrix for thin clients it turned out it would've been cheaper deploy desktops and we would've had a lot of change out of that. For 10,000 desktops I imageine the management benefits and other facilities bring you real savings. For 30, like I have, or the OP's 100, it's just not worth the outlay IMO.
Since not even the basic Terminal Server turned out to be especially useful for us once CALs were factored in, I think Citrix would've been nuking a fly (and those nukes are pricey things).
I've been using thin clients at work for a while (LTSP based - netbooted X11 thin clients). They work very well, and I'm fairly happy with the results (some of the software could be less buggy, but that's OSS for you). They're delightfully easy to manage, in that they require essentially none. Unfortunately the server side configuration tools for user's desktop environments and apps are almost non-existent so you'll have to do a lot more rolling-your-own than you'd probably like.
Unfortunately, I'm having real troubles with the vertical market vendors as we seek a new newspaper accounts & bookings system. They *all* require Windows desktops - many don't even work with TS / Citrix. Consider this factor VERY carefully before deciding on a thin client roll out, especially Linux thin clients.
How well it works will depend a lot on how much in-house development you do... and in-house development is *expensive* (in time, if nothing else) to a small/medium business.
I share your opinion on TS and CALs. I don't see the point - the CALs negate most of the lower outlay of thin clients. Citrix makes it even worse. Unless you expect to save a *lot* on management and running costs, I don't see how it's worth it.
I work regularly on a real SMP system, I and consequently I've been drooling for dual core since I first heard the x86 CPU vendors were (finally) getting around to adding it.
SMP makes a massive difference on a system - if your workloads benefit. Mine do - I spend a lot of time compiling things, and the compiling (on the right codebase) tends to scale in an almost linear way with number of CPUs. Not only does SMP make this vastly faster, but it leaves your system so much more responsive that it's hard to believe.
Even if dual core CPUs have only half the benefits (I imagine the Intel ones will, given their memory bandwidth needs) I'd still be really tempted. The power consumption is a nasty issue though.
Good point. They'd have to work from a pre-generated finite set of keys, since otherwise old discs wouldn't play on new players (the disc wouldn't have a suitable symmetric key encrypted with the player key, since the player key didn't exist at the time) but it should work unless someone "in the know" leaks the whole keyspace or something.
It would certainly make life harder on the attacker, since a design issue that permitted older models to be cracked could be rectified and a new key assigned without sacrificing backward compatibility with older discs.
Personally, I wish they'd just give up and go away. I'll just stop buying films entirely if I can't watch them in peace, and it's already getting close to that point already. Only open source DVD players and DVD player hacks that introduce a certain disrespect for skip blocking etc are keeping me interested as it is.
That seems reasonable, though I think it very unlikely that players could be updated from the 'net with new keys. Keys over the 'net just smells like a key-stealing party, plus most players will be set-top and not exactly convenient to an Internet connection.
My personal suspicion is that if the hardware's protection is broken once to get one key, the other 99 are probably also toast. I guess it depends on the type of break and how expensive it is (time + money).
I'm afraid I think you read it wrong.
..." is the key phrase. A given model, if this is the same as CSS, has a CSS key - not a given unit of that model. Revoking the key would revoke it for all units of that model since they all have the same key.
"... with the compromised set of keys
Nasty. DVD is offensive enough already ("You may not skip this!"), this will just make it worse. Argh.
With most such set-ups your Internet connection is generally not totally blocked, just severely restricted. Any web request gets proxy-redirected to a page with instructions on how to clean your machine up, and download links from the ISPs local mirrors. Anything else is locked down.
I don't know if this is what bigpond are doing, but that's the usual way to handle this and it seems to work extremely well. My ISP uses a similar trick when users go over quota.
Yep.
Actually, with many such set-ups the user opens their web browser and gets proxy-redirected to a page explaining what they need to do to fix their computer, complete with download links and moron-proof instructions. An email appears in their mailbox explaining the same thing, and everything else is firewalled off at the router.
Quite cool, really.
Ditto. In both senses - that is, been there done that, and "use the program `ditto' to do it".
`ditto' is the program the Mac developers wrote instead of tweaking all the UNIX utilities to work with their dual-forked filesystem. Never, ever, ever use `cp' on MacOS/X - only `ditto'.
Guess what isn't mentioned in the `cp' man page?
I suspect the author may have spent too much time around Douglas Adams. This is so overdone that I strongly suspect he's having a laugh himself.
I'm not satisfied by OS/X, and I'm no free software zealot. I don't want complete tweakability and control (KDE drives me nuts for that reason) either, though I do want some minimal control - turn off all the godamm "eye candy", mostly.
I'm not satisfied with it because I need a UNIX platform for most of my work, and MacOS/X is not UNIX. It has a UNIX/BSD compatible subsystem, but uses a different binary format, "interesting" linker arguments, has different shared library handling, and has a relatively poorly integrated X11 environment (X11 its self works great, but launching apps etc is PITA) that isn't installed by default. It's UNIX-compatible enough that apps need little porting to run under X11, but it ain't UNIX.
My solution to this is very simple - don't buy Apple hardware. I don't see the point in buying an Apple machine only to try to kludge Linux onto it - it'll never work particularly great (Apple aren't big on open sourcing drivers or releasing specs) and it'll cost more for the power you get.
So
I can agree with you on some points, but as a long-time UNIX _and_ Linux user and more recent MacOS/X user, not all.
.pkg-based Aqua ones, without using AppleScript hacks, and (b) X11 apps could get their own dock entries etc. As I work on porting to MacOS/X, I'm increasingly learning that neither of these would be excessively hard for Apple to do. I just don't think they want to.
2: X11 doesn't come pre-installed, it has to be custom-installed by the user though it is shipped with the OS. A most unfortunate decision in my book.
5: Doing this largely denies you access to the system admin tools etc. It also means you still have the non-trivial overhead of Aqua, the Finder, etc.
More importantly, it doesn't change the fact that you're running on an OS with several fundamentally different ideas of what an "application" is ("native" Aqua, X11, console, Java, etc).
It also has a different binary format (Mach-O), a strange linker (-framework anybody? Why didn't they at least make it -framework,name,name like the rest?!?), and other differences that make it hard to treat it as a generic *nix.
Oh yeah, and Apple X11 seems really slow compared to the versions I use on other platforms, which doesn't help. OTOH, perhaps that's because I use it on an eMac.
6: Would be more true if (a) you could launch X11 apps from the file manager and dock as easily as
Now, for most users, who cares. They're happy with OS/X. If you're looking for, say, a PPC UNIX devel machine, though, this sort of thing makes sense. I still think it's utter BS for the proposed use - cheap desktops.
I'm not sure it makes sense as a "cheap computer" approach. I'd argue that it's hardly pointless, though:
... it has a UNIX/BSD subsystem, but it sure ain't UNIX. I found that one out first hand as I helped port Scribus to it (still in progress). Mach-O, Aqua, Carbon, Cocoa, weird font formats, weird FS layout, etc. Not bad, but not UNIX.
(a) Some folks like mac hardware but can't stand MacOS/X . I'm not one of them, but I prefer using a more "true" UNIX with a single, consistent API and with well-integrated X11.
(b) Other folks are developing PowerPC applications for UNIX. Linux, being much more "unix-y" than MacOS/X, will be a much better fit for that sort of role.
Yes, I know Apple says OS/X is UNIX. Well
One possible reason is to give them room to move in the market. They can now, if this article reflects the general nature of these CPUs, ramp their clock speeds in a hurry if they need to. In the mean time, they can keep slowly upping the speeds and keep the higest speed ones priced to the max.
I'm Australian. I don't even watch TV anymore because it's so filled with utter crap, because I can't stand the commercials, and because I see the few things I care about at friends places months and sometimes years before it hits TV here.
Pay for downloaded shows? At decent rates, with guaranteed quality and no stuffing around? HELL YES, even if it's a buck an episode or something (adds up compared to renting the DVD later). <i>But only if there are no ads.</i> They grate on my so badly I just can't stand watching TV now, and that wouldn't change with downloaded episodes.
I'd like to think the service would not be DRM'd up the wazoo (given that the episodes can be obtained easily enough with bittorrent etc anyway, so it's not like they'd actually be protecting anything much), but I doubt we'd be that lucky.
Right click properties, relational integrity constraints and stored procedures, they're all the same to me! :-P
As I alluded to when responding to another response to my post, I'm aware that's a factor. It's not, however, what pays the bills in the short/medium term.
I also tend to view the situation with "creative" apps as quite different to with OSes. It's much easier to just use whatever Linux distro is currently in vogue and looks attractive for your needs; they just don't take that much distro-specific learning. The same is not true of desktop publishing or high-end web authoring packages.
Because of this, I don't think mind share is really that big a deal with Linux distros. The chances are the PHBs will make the distro selection anyway, and they'll probabably just pick the most familar sounding name / the lowest price / the one that offers them the best kickback on the deal.
Well, there's is arguably the indirect "mind share" effect - but that's about it, really. That's also a very long term thing, and the context of this article really isn't about long term.
Thus, perhaps you'd like to expound upon your reasoning behind your accusation of my ignorance? Otherwise you're at risk of showing your own arrogance and inability to communicate a point instead of simply sniping - and you wouldn't want that.
I freely admit I'm in many ways ignorant, but I don't see how this has anything to do with any of them.