Except that the comparison falls apart when you look at a particular detail of the issue.
Comparing Monsanto vs. 'normal' crops to closed- vs. open-source doesn't work when you factor in the issue of Monsanto suing farmers whose fields are contaminated by seeds from neighboring farmers.
That's like if you're an open-source company and the company next door makes closed-source software, and suddenly, without you doing anything or even knowing what they do, you've violated their copyright and they're suing your company.
Microsoft isn't very ethical, sure, but Monsanto is selling their seeds to one farmer, and then suing all the neighbours that didn't pay up, because they know full well that seeds will spread no matter what.
Now the reason I think you're wrong is because last time I posted a rant like this, two Mac users pointed out that Photoshop on the Mac does not work like this. Apperently, clicking on any image open in photoshop also brings the tools into focus as well. Of course I could be wrong as well, since I have no direct experience with Photoshop on Macs. Photoshop on Mac or Windows (or any decent editing software) will in fact do exactly as you describe. This happens in Photoshop, Illustrator, Word, Powerpoint, iWork, and any other well-designed software I've used (and yes, Word is better designed than GIMP is).
In fact, Photoshop has an even cooler feature - the tab key toggles display of the tool palettes. The huge benefit that this provides is that you can fullscreen your editor to avoid any other distractions (or just to maximize viewing space), or even have it take over the entire monitor (so Photoshop's canvas uses every pixel of the monitor). You pick a tool, hit tab, and the palettes disappear. Do your editing, hit tab again, they come back, change your layer, tab again.
I've yet to see GIMP offer even this (relatively simple) feature for image editing. Oh, wait, I know why - it's "not Photoshop". Great.
Except that the GIMP uses full-fledged windows for tool palettes, meaning that they could end up above (or behind) applications, despite the main document application being in front; Photoshop, in contrast, uses toolbars, which are 'always on top' when Photoshop is the active application, meaning you'll never lose your toolbars.
Also, this means that toolbars never show up in Expose or spaces, or in advanced task-switchers like Witch; GIMP's toolbars also, last I dealt with it, showed up in the GNOME panel, resulting in a half-dozen entries just to edit one image.
Toolbars are not windows. Seriously. I hope this is one of the fixes, or it's going to keep being treated like a half-baked toy.
If you want the Photoshop interface, check out GIMPshop [wikipedia.org]. It doesn't seem to be very popular though, I guess not EVERYONE is hankering for a Photoshop interface. More likely the professional users that want Photoshop just go out and spend the money to get actual Photoshop - including some pretty badass integrations with the rest of the Creative Suite apps, not to mention running natively on Windows and OS X.
GIMPshop is for people who want to use Photoshop, but are on Linux, or who are trying to migrate casual Photoshop users (such as pirate hobbyists) off Windows to Linux.
I'll second this - Dotster is the one I've used for years, and the one I've suggested to every company I've ever worked for or with, and anyone I've ever met who wants to buy a domain. All my friends use them, and no one has had a single complaint about them for over a half-decade.
Well, there's the problem... If you strip Vista down for embedded application, it compares favorably to XP... but if you strip XP down, it doesn't come close. I pointed this out in my other, more detailed post.
When you strip everything 99% of users want out of XP, it goes from ~600M to ~150M. When you do the same to Vista, it goes from ~2-4GB to ~600M.
I'd imagine a lot of that is Vista's purported 'multiple DLL versions', which keeps every version of each DLL, so that apps that need a specific one will get it... but still, that seems absurd to me, and it doesn't explain the bloat in system requirements.
Let's face it, whatever Microsoft did to cock up Vista so badly, it was enough that even if they wanted to they couldn't build a good OS off it. Just like the Pentium M was a fantastic chip based not off the then-current P4 but the previously-retired P3, so too would Microsoft have to build their next-generation OS off XP at best, unless they refused to acknowledge (internally) their abhorrent failures.
You can trim a 600M Windows XP image down to about 120M if you know for sure you won't be using a lot of functionality, or 150M to keep all the functionality that 99% of users use (e.g. taking out the ATM networking and Trident drivers). This keeps a LOT of functionality that you don't need on mobile devices (mostly user space apps), and includes things like SP3, Windows Update updates, NVidia drivers, and so on.
Such installs, when automated, tend to take, in my experience, around ten minutes off a disk image in a VM, compared to an hour and a half for installation (not counting the time wasted when you don't know it's asking you a question because you're off being productive elsewhere), plus the hours and hours of installing drivers for networking and video, rebooting, updating Windows Update, rebooting, running Windows Update, rebooting, running Windows Update again, rebooting, and so on.
You can trim a Windows Vista installation (between 2GB-4GB, according to TPB) down to around 600M, trimming out all the crap that I personally couldn't afford to lose. The result was so absurd that I just wiped it out without bothering to test it.
So, if Windows Vista is really just 'XP with prettyness and UAC' why is it an extra 450M? It's not drivers (I wiped out everything that Vista comes with). It's not useful apps or productivity tools (everything Windows comes with, I replace). So where's it all going?
I know there are a lot of under-the-hood changes, but certainly for the loss of performance, ballooning of requirements, complexity and frustration, certainly it can't be justified... can it?
In regards to #2 in the enterprise (health care) environment I work in, and some things I've seen...
Applications will not install without administrator access. This is good. Except they WILL install into places where users have rights (e.g. their home directories). That's not so bad. They will then assume that they can write to anywhere (e.g. c:\myappdata) which will fail. Many programs ($2500+ per-set apps) will not check error codes, so they will fail silently. Others will fail with cryptic error messages. Most will not allow the user to change settings to something that will work.
Some applications WILL install, if you 'Run as...', including one I tried to install the other day. The problem there was that the system needed a reboot (which I performed), but also required doing some post-installation, post-reboot configuration, which can only be done as an admin (which I did not know, and was not told). As a result, the program did not work after rebooting, with no indication as to why. Also, applications cannot be REMOVED via privilege escalation, which means (on an AD domain) logging the user out and losing their workspace. This is, in fact, the only way I found out that this app needed post-installation configuration.
In this case, I was doing an upgrade of software from one version to another, which I've done many times before with no issues whatsoever. In this case, it failed, and the software was unusable. I was forced to uninstall and reinstall, which wiped all my locally stored data (a few gigabytes for me; for a production workstation, potentially dozens or hundreds of gigs of data).
Part of the reason I couldn't figure out what was going on was because the program uses three Windows services, which my user doesn't have rights to access; as a result, every time I wanted to use the app's 'Process Manager' to rebuild its database, it told me I had to log in as an admin (or 'Run as...').
On Linux, OS X, or a Windows system logged in as Administrator, this process would have taken about five to ten minutes, including the reboot. The actual ordeal took me around two hours.
This was an extreme case. Some apps will outright refuse to install if they can't write to C:\Program Files; some installers will refuse to run as a non-admin, even though installing them to a USB drive (for example) works perfectly on any computer you plug it into.
All I can say is thank god for OS X's approach. One 'app' to drag around; installers for complicated ordeals (e.g. customizing Office installs), and.pkg/mpkg files for installing software remotely via ARD (or ssh). Hooray.
Seriously Microsoft, you need to fix this, and bad.
In fairness, the article references a new version of the SDK that contains a new firmware... the SDK which, by the way, includes all of XCode, which is something like 2 GB total. Preposterously huge, and it still shows the same version on the website, so the more intelligent someone is, the more likely they're going to check the version, and the more likely they are to get screwed.
So, for those people who got the e-mail, downloaded without checking the version to see if the 2G download was worth it, managed to get the whole thing from the ADC site (presumably it was swamped, maybe not since most people don't care like they did at release), and installed the new firmware, no problem.
For anyone who didn't get the e-mail on time, didn't realize that the expiry was going to 'brick' (actually, temporary disable) their phone, checked the version number and discounted the download as redundant, or couldn't get it down in time, they got hosed.
And frankly, if I got that e-mail and saw the same version as I already had, I'd say 'Oh, I have that, I'm going to be fine.'
I'm a huge Apple fanboi, but let's face it, people kind of got hosed on this one.
I bricked my Macbook the other day, it sucked. I had to move the cursor so the screen woke up, then type in my password. Damnit Apple, why do you keep bricking this thing every five minutes? *rage*
What is it with the overuse of the term 'bricked' lately? These phones are NOT bricked. They are not usable as phones right now, but they can be easily fixed by restoring older firmware, or installing newer firmware. There's even a way to keep using the current firmware without the PSOD.
So, ignoring the fact that you can only 'brick' a device once (after which point is is worthless anyway), anyone who installs as-yet-unreleased beta firmware on their phone should be fully aware that something unpleasant could well happen. If this were foolproof, Apple would have shipped out the new firmware to *everyone*.
To mix some metaphors, if you want to play with the big boys, you're going to get burned.
The impression I got from Bell's argument is something like this:
What they said: The market was opened up for competition, but now there's enough competition so we shouldn't have to still hold their hands.
What they mean: People are competing with us, despite the fact that we own the network and fuck around so badly with our wholesale clients that their problems never get solved in a reasonable amoutn of time, and instead of fixing our ludicrously broken processes or continuing to lose out to people who use our network better than we do, we want our monopoly back.
Bell does have a point; a lot of companies (like one ISP I worked for for almost a week after my training ended) just keep reselling Bell's and Telus's services (despite getting dicked around all the time); they have essentially the same prices, plans, and service as Bell, but it takes longer to get anything done because you're one more step removed from the technicians.
An ISP a friend worked for, however, took the other route. After selling Bell's service in Montreal, they hired my friend to do their ADSL rollout. They bought their own bandwidth, installed their own DSLAMs, and started moving customers over, and you know what? Paying for bandwidth directly was cheaper for them than leasing an essentially unlimited line from Bell.
As a result, they started moving all of their customers over from Bell's per-customer charges to their third-party's per-megabit rates, and they're saving tons of money - enough to use to buy the new ADSL2+ equipment and move even more people over.
The lesson is: Don't wait for Bell to stop being dicks; do things right yourself and it pays off.
The Cocoa API is also being unofficially open-source ported to other platforms (most actively Windows platforms) through the intriguing Cocotron project. It's still a work-in-progress, mind you.
Every portable API uses Carbon, not because of high-level vs. low-level, but because Carbon can be easily integrated with existing C/C++ code, whereas Cocoa requires a little more effort. Carbon provides what a lot of Mac users consider a sub-standard experience, and worse integration, but for most people porting their apps to Mac, they rarely know or care.
In OS X, there's not a lot of 'communication' that needs to be done to make the window 'less blank', though I'm not sure exactly what that means. You can put together a UI in Interface Builder, put your code into XCode and add whatever the Mac port needs, compile it together, and off you go.
You can write most of your app in C++, write the GUI-management code in Obj-C (or Obj-C++), and then glue it all together with Obj-C++.
Well C++ developers can opt to use Obj-C++ for their glue code, which is going to be 'similar enough' for any good C++ programmer. There's no requirement to rewrite your application - just rewrite the GUI code (which you have to do anyway) and any OS-dependent code, and you're off to the races.
If nothing else, hire an Obj-C programmer on contract to do the integeration for you, and they'd proably do a better job than someone new to the platform would anyway.
No, they shouldn't be called that, and VMs do more than what you say they do.
A virtual machine doesn't just execute the raw machine code on the raw machine. There are a lot of things you need to be aware of and intercept. For example, if a process tries to change the processor to/from protected mode (Intel) or change the endianness (PPC), you have to intercept those calls and determine what to do. In the case of the former, you would change to emulating protected mode (32-bit). In the case of endianness, you have to now keep track of when to be a different endian and when not to be. How do you implement this? By doing it in software? Or by changing the endianness of the host processor when you need to execute that process's code? But then what about running your own code? Do you switch it back when you're NOT passing through that app's raw code? Complicated.
I/O is another headache with VMs, but generally the reason for that is because of overhead. For example, a program writes to a file; the OS manages the write to the file, with the overhead of the filesystem (where to put it on disk, whether or not to fragment it and how, etc). The OS then writes to the 'disk', which the VM intercepts and writes to a file on the filesystem on a real disk (presumably). Fun.
Providing a whole virtual machine doesn't necessarily provide the benefits that Microsoft is looking for here. There's not a lot of sense in virtualising an entire operating system; while Apple managed a similar thing with their Classic environment, which would be what Microsoft would want to copy, virtualising on the level of VMWare is overkill, and adds more complexity than should be necessary (though it does provide some benefits as well).
If Vista were Microsoft's Copland, then they would have realized that it was going to be a failure, and taken the good technologies to add to their existing products. Instead, they realized that it was going to be a failure, and so restricted many technologies (e.g. DirectX 10) to Vista in order to force adoption.
It's obvious Microsoft knew that people wouldn't want Vista in the quantities that they needed; their solution, instead of fixing it, was to force it on people instead. Sad.
Videotron in Quebec offered a similar service; even if you were on their 600 kbit connection, you could buy, for $5, access to their 10mb connection for 48 hours. Great for people who torrent, but rarely, or who legitimately download large files (Fedora ISOs?). Pretty nice. Never used it myself, but great for grabbing those 'Complete season 2' torrents.
I worked for a company that did mobile data collection software, including actual survey design (flowing questions, ask this question based on this question's answer, filter these responses, ask this set of questions once for each child listed in previous questions, etc.).
This stuff is trivial to implement if you do it right, and all it takes is commodity Palm hardware (or PocketPC hardware running an emulation layer, or Windows tablets). It's trivial to do, syncs automatically, and can export all the data in a format easily used for generating whatever reports or correlations you want. The fact that the government is screwing this up (or rather, their contractor is) is just an example of not shopping around (or perhaps limiting their shopping to only American companies).
There's no reason that it should cost anywhere as much as it does, unless they're hiring way too many people (or can't manage the travelling salesperson problem). It's just a mismanaged government cock-up, is all.
Except they don't go to everyone's house at a time when people are likely to be home (necessarily). My mail sure as heck doesn't come when I'm home, and only when I was working graveyard shifts in the past has that ever happened. The problem with censuses is that they're not just going door-to-door, it's going door-to-door and asking questions of people over the age of 18 who live there. That's why they need census-takers.
I think the worst part of it is that the systems that are rejecting mail (because they're still configured to use ORDB) are the ones that are the least-maintained, and quite possibly completely forgotten about - and therefore are least likely to be noticed quickly or fixed intentionally.
That said, if you're that crappy of a sysadmin, you deserve a wake-up call. It's just too bad that other people have to suffer for you to learn to do your job properly.
Another example I've seen on several occasions is a system Apache (compiled against a system openssl) loading a custom PHP compile (compiled against a local openssl from/usr/local). Suddenly you have two similar-but-different versions of SSL. I've seen situations where this breaks completely, and situations where the linker figures out (at run-time) that you've already got libssl loaded, and things break unexpectedly.
This is further exacerbated when dependencies get more complicated. Apache-SSL with SSL-enabled PHP loading MySQL and Postgres compiled with SSL support gives you four different points where the wrong version could be expected/required. Similarly, practically everything you ever compile links against zlib, or links against something that does. Lots of points of failure.
This is why, IMHO, it's important to use a system which allows you to simply and easily update important libraries in a way that doesn't break existing applications (or breaks them predictably, in every case, so you know what will need fixing). This is one thing I don't trust RHEL for; Debian, on the other hand, tends to handle this well (and presumably, by extension, Ubuntu as well).
...but it's real challange lies ahead: convincing folks to stop buying DVDs and DVD players (which can be had for thirty dollars) and buy Blu-Ray discs and players... This is a task that electronics retailers (such as Best Buy) are in a real position to do with side-by-side demonstrations. Heck, I was in a Future Shop on Boxing Day and saw two identical televisions - identical except that one was the 1080i model, and one was 1080p - and I could tell the difference. It was subtle, but it was there. Showing someone a 1080p Blu-Ray feature next to the 480p DVD feature on the same television is going to be a pretty convincing show.
The real trick is going to be getting the same content on both TVs, despite different sources. Perhaps downsamping the HD version, then letting the TV upscale it, would be a demonstration? Hard to say. Still, that would make a lot of sales.
80. (1) Subject to subsection (2), the act of reproducing all or any substantial part of
(a) a musical work embodied in a sound recording,
(b) a performer's performance of a musical work embodied in a sound recording, or
(c) a sound recording in which a musical work, or a performer's performance of a musical work, is embodied
onto an audio recording medium for the private use of the person who makes the copy does not constitute an infringement of the copyright in the musical work, the performer's performance or the sound recording. Subsection 2 disclaims this privilege for renting, selling, or performing, as well as distribution. Thus, it is legal to make a copy of a friend's CD for your personal use, but not legal for your friend to make a copy of his CD for your personal use. Opinion has varied, but the general consensus (including that of the courts, IIRC) is that internet filesharing involves the recipient making the copy, which thus falls under subsection 1 but is not excluded by subsection 2.
Note that this section of the act applies specifically to audio recordings, and specifically to 'an audio recording medium', but since audio can be recorded onto pretty much any digital medium, I doubt that that qualifier makes that much of a difference.
The biggest problem with targeting Linux, be it for games or any other commercial program, is ambiguity and the 'moving target' nature of Linux.
Ambiguity: How do you support Linux? You can't, really. What you have to do (in a practical sense) is support a distribution of Linux - for example, Fedora or Ubuntu. But then what of all the others? For every grateful Ubuntu user, there's going to be an irate Gentoo user who complains that his system isn't 'supported' (replace Ubuntu and Gentoo with any two differing distros). How do you support Linux, when 'Linux' is such a general term, and the variations can be so different?
Moving Target: What do you support? FC5? 6? 7? 9? The latest-and-greatest? Two years' worth? The last two versions? This gets especially complicated if they try to support more than one distribution. Do you target the latest two releases of Ubuntu, and the last three of Fedora? The latest two of each? What if Ubuntu releases faster? What if it has more 'latest and greatest' support (libraries, Xorg, etc.). What about drivers? Will these distros work properly with the included drivers? with binary drivers? will the game work properly with both?
How do you deal with support? Do you train your support monkeys on Windows, then run them through a six-week course on Fedoras 5 through 9, and the last three Ubuntus? What if the users are using an older Ubuntu that isn't support (but on which it should work)? What if a user has problems with the stock (open-source) NV driver? Do you recommend the closed-source one? What if they don't want to use that one, for whatever reason? What if they use it and then upgrade their kernel and it stops working? More likely, what if the system upgrades it for them?
What about DirectX? It doesn't port. You'd have to rewrite with OpenGL, OpenAL, rewrite your networking code, your 2D acceleration code, image handling, surfaces, media playback... or I suppose you could pay more to license Crossover's tech, similar to the move EA made for Mac games... but that increases your costs as well. You'd have to replace all of your Win32 API code (simple, common stuff like opening files, etc.) with cross-platform wrapper functions or #define statements. You'd have to test on both platforms.
Can it be done? Of course! Blizzard does it. If you inspect the Blizzard binary, you find a collection of strings, including 'Win95', 'Win98', 'Win2K', 'WinME', 'WinXP', 'MacOS9', 'MacOSX', and 'Linux'. Interesting. But is it worth it for most companies to hire programmers to write cross-platform code? Or is it just easier to target the large, stable, reliable, stationary target that is Windows, and leave the 2% gain that a Linux version might provide?
Don't forget, companies have existed to bring games to Linux. They failed. There's a reason.
Slashdot Mirror
Except that the comparison falls apart when you look at a particular detail of the issue.
Comparing Monsanto vs. 'normal' crops to closed- vs. open-source doesn't work when you factor in the issue of Monsanto suing farmers whose fields are contaminated by seeds from neighboring farmers.
That's like if you're an open-source company and the company next door makes closed-source software, and suddenly, without you doing anything or even knowing what they do, you've violated their copyright and they're suing your company.
Microsoft isn't very ethical, sure, but Monsanto is selling their seeds to one farmer, and then suing all the neighbours that didn't pay up, because they know full well that seeds will spread no matter what.
In fact, Photoshop has an even cooler feature - the tab key toggles display of the tool palettes. The huge benefit that this provides is that you can fullscreen your editor to avoid any other distractions (or just to maximize viewing space), or even have it take over the entire monitor (so Photoshop's canvas uses every pixel of the monitor). You pick a tool, hit tab, and the palettes disappear. Do your editing, hit tab again, they come back, change your layer, tab again.
I've yet to see GIMP offer even this (relatively simple) feature for image editing. Oh, wait, I know why - it's "not Photoshop". Great.
Except that the GIMP uses full-fledged windows for tool palettes, meaning that they could end up above (or behind) applications, despite the main document application being in front; Photoshop, in contrast, uses toolbars, which are 'always on top' when Photoshop is the active application, meaning you'll never lose your toolbars.
Also, this means that toolbars never show up in Expose or spaces, or in advanced task-switchers like Witch; GIMP's toolbars also, last I dealt with it, showed up in the GNOME panel, resulting in a half-dozen entries just to edit one image.
Toolbars are not windows. Seriously. I hope this is one of the fixes, or it's going to keep being treated like a half-baked toy.
GIMPshop is for people who want to use Photoshop, but are on Linux, or who are trying to migrate casual Photoshop users (such as pirate hobbyists) off Windows to Linux.
I'll second this - Dotster is the one I've used for years, and the one I've suggested to every company I've ever worked for or with, and anyone I've ever met who wants to buy a domain. All my friends use them, and no one has had a single complaint about them for over a half-decade.
I can't recommend them highly enough.
Well, there's the problem... If you strip Vista down for embedded application, it compares favorably to XP... but if you strip XP down, it doesn't come close. I pointed this out in my other, more detailed post.
When you strip everything 99% of users want out of XP, it goes from ~600M to ~150M. When you do the same to Vista, it goes from ~2-4GB to ~600M.
I'd imagine a lot of that is Vista's purported 'multiple DLL versions', which keeps every version of each DLL, so that apps that need a specific one will get it... but still, that seems absurd to me, and it doesn't explain the bloat in system requirements.
Let's face it, whatever Microsoft did to cock up Vista so badly, it was enough that even if they wanted to they couldn't build a good OS off it. Just like the Pentium M was a fantastic chip based not off the then-current P4 but the previously-retired P3, so too would Microsoft have to build their next-generation OS off XP at best, unless they refused to acknowledge (internally) their abhorrent failures.
You can trim a 600M Windows XP image down to about 120M if you know for sure you won't be using a lot of functionality, or 150M to keep all the functionality that 99% of users use (e.g. taking out the ATM networking and Trident drivers). This keeps a LOT of functionality that you don't need on mobile devices (mostly user space apps), and includes things like SP3, Windows Update updates, NVidia drivers, and so on.
Such installs, when automated, tend to take, in my experience, around ten minutes off a disk image in a VM, compared to an hour and a half for installation (not counting the time wasted when you don't know it's asking you a question because you're off being productive elsewhere), plus the hours and hours of installing drivers for networking and video, rebooting, updating Windows Update, rebooting, running Windows Update, rebooting, running Windows Update again, rebooting, and so on.
You can trim a Windows Vista installation (between 2GB-4GB, according to TPB) down to around 600M, trimming out all the crap that I personally couldn't afford to lose. The result was so absurd that I just wiped it out without bothering to test it.
So, if Windows Vista is really just 'XP with prettyness and UAC' why is it an extra 450M? It's not drivers (I wiped out everything that Vista comes with). It's not useful apps or productivity tools (everything Windows comes with, I replace). So where's it all going?
I know there are a lot of under-the-hood changes, but certainly for the loss of performance, ballooning of requirements, complexity and frustration, certainly it can't be justified... can it?
You and I know there's no UID-based class system, but don't try to explain that to these high-digit kids, because you know they just won't get it. ;)
In regards to #2 in the enterprise (health care) environment I work in, and some things I've seen...
.pkg/mpkg files for installing software remotely via ARD (or ssh). Hooray.
Applications will not install without administrator access. This is good. Except they WILL install into places where users have rights (e.g. their home directories). That's not so bad. They will then assume that they can write to anywhere (e.g. c:\myappdata) which will fail. Many programs ($2500+ per-set apps) will not check error codes, so they will fail silently. Others will fail with cryptic error messages. Most will not allow the user to change settings to something that will work.
Some applications WILL install, if you 'Run as...', including one I tried to install the other day. The problem there was that the system needed a reboot (which I performed), but also required doing some post-installation, post-reboot configuration, which can only be done as an admin (which I did not know, and was not told). As a result, the program did not work after rebooting, with no indication as to why. Also, applications cannot be REMOVED via privilege escalation, which means (on an AD domain) logging the user out and losing their workspace. This is, in fact, the only way I found out that this app needed post-installation configuration.
In this case, I was doing an upgrade of software from one version to another, which I've done many times before with no issues whatsoever. In this case, it failed, and the software was unusable. I was forced to uninstall and reinstall, which wiped all my locally stored data (a few gigabytes for me; for a production workstation, potentially dozens or hundreds of gigs of data).
Part of the reason I couldn't figure out what was going on was because the program uses three Windows services, which my user doesn't have rights to access; as a result, every time I wanted to use the app's 'Process Manager' to rebuild its database, it told me I had to log in as an admin (or 'Run as...').
On Linux, OS X, or a Windows system logged in as Administrator, this process would have taken about five to ten minutes, including the reboot. The actual ordeal took me around two hours.
This was an extreme case. Some apps will outright refuse to install if they can't write to C:\Program Files; some installers will refuse to run as a non-admin, even though installing them to a USB drive (for example) works perfectly on any computer you plug it into.
All I can say is thank god for OS X's approach. One 'app' to drag around; installers for complicated ordeals (e.g. customizing Office installs), and
Seriously Microsoft, you need to fix this, and bad.
In fairness, the article references a new version of the SDK that contains a new firmware... the SDK which, by the way, includes all of XCode, which is something like 2 GB total. Preposterously huge, and it still shows the same version on the website, so the more intelligent someone is, the more likely they're going to check the version, and the more likely they are to get screwed.
So, for those people who got the e-mail, downloaded without checking the version to see if the 2G download was worth it, managed to get the whole thing from the ADC site (presumably it was swamped, maybe not since most people don't care like they did at release), and installed the new firmware, no problem.
For anyone who didn't get the e-mail on time, didn't realize that the expiry was going to 'brick' (actually, temporary disable) their phone, checked the version number and discounted the download as redundant, or couldn't get it down in time, they got hosed.
And frankly, if I got that e-mail and saw the same version as I already had, I'd say 'Oh, I have that, I'm going to be fine.'
I'm a huge Apple fanboi, but let's face it, people kind of got hosed on this one.
I bricked my Macbook the other day, it sucked. I had to move the cursor so the screen woke up, then type in my password. Damnit Apple, why do you keep bricking this thing every five minutes? *rage*
What is it with the overuse of the term 'bricked' lately? These phones are NOT bricked. They are not usable as phones right now, but they can be easily fixed by restoring older firmware, or installing newer firmware. There's even a way to keep using the current firmware without the PSOD.
So, ignoring the fact that you can only 'brick' a device once (after which point is is worthless anyway), anyone who installs as-yet-unreleased beta firmware on their phone should be fully aware that something unpleasant could well happen. If this were foolproof, Apple would have shipped out the new firmware to *everyone*.
To mix some metaphors, if you want to play with the big boys, you're going to get burned.
The impression I got from Bell's argument is something like this:
What they said: The market was opened up for competition, but now there's enough competition so we shouldn't have to still hold their hands.
What they mean: People are competing with us, despite the fact that we own the network and fuck around so badly with our wholesale clients that their problems never get solved in a reasonable amoutn of time, and instead of fixing our ludicrously broken processes or continuing to lose out to people who use our network better than we do, we want our monopoly back.
Bell does have a point; a lot of companies (like one ISP I worked for for almost a week after my training ended) just keep reselling Bell's and Telus's services (despite getting dicked around all the time); they have essentially the same prices, plans, and service as Bell, but it takes longer to get anything done because you're one more step removed from the technicians.
An ISP a friend worked for, however, took the other route. After selling Bell's service in Montreal, they hired my friend to do their ADSL rollout. They bought their own bandwidth, installed their own DSLAMs, and started moving customers over, and you know what? Paying for bandwidth directly was cheaper for them than leasing an essentially unlimited line from Bell.
As a result, they started moving all of their customers over from Bell's per-customer charges to their third-party's per-megabit rates, and they're saving tons of money - enough to use to buy the new ADSL2+ equipment and move even more people over.
The lesson is: Don't wait for Bell to stop being dicks; do things right yourself and it pays off.
You can see Ars Technica's writeup on the Cocoa port of QT4 for more information on how they've actually done so far.
The Cocoa API is also being unofficially open-source ported to other platforms (most actively Windows platforms) through the intriguing Cocotron project. It's still a work-in-progress, mind you.
Every portable API uses Carbon, not because of high-level vs. low-level, but because Carbon can be easily integrated with existing C/C++ code, whereas Cocoa requires a little more effort. Carbon provides what a lot of Mac users consider a sub-standard experience, and worse integration, but for most people porting their apps to Mac, they rarely know or care.
In OS X, there's not a lot of 'communication' that needs to be done to make the window 'less blank', though I'm not sure exactly what that means. You can put together a UI in Interface Builder, put your code into XCode and add whatever the Mac port needs, compile it together, and off you go.
You can write most of your app in C++, write the GUI-management code in Obj-C (or Obj-C++), and then glue it all together with Obj-C++.
Well C++ developers can opt to use Obj-C++ for their glue code, which is going to be 'similar enough' for any good C++ programmer. There's no requirement to rewrite your application - just rewrite the GUI code (which you have to do anyway) and any OS-dependent code, and you're off to the races.
If nothing else, hire an Obj-C programmer on contract to do the integeration for you, and they'd proably do a better job than someone new to the platform would anyway.
No, they shouldn't be called that, and VMs do more than what you say they do.
A virtual machine doesn't just execute the raw machine code on the raw machine. There are a lot of things you need to be aware of and intercept. For example, if a process tries to change the processor to/from protected mode (Intel) or change the endianness (PPC), you have to intercept those calls and determine what to do. In the case of the former, you would change to emulating protected mode (32-bit). In the case of endianness, you have to now keep track of when to be a different endian and when not to be. How do you implement this? By doing it in software? Or by changing the endianness of the host processor when you need to execute that process's code? But then what about running your own code? Do you switch it back when you're NOT passing through that app's raw code? Complicated.
I/O is another headache with VMs, but generally the reason for that is because of overhead. For example, a program writes to a file; the OS manages the write to the file, with the overhead of the filesystem (where to put it on disk, whether or not to fragment it and how, etc). The OS then writes to the 'disk', which the VM intercepts and writes to a file on the filesystem on a real disk (presumably). Fun.
Providing a whole virtual machine doesn't necessarily provide the benefits that Microsoft is looking for here. There's not a lot of sense in virtualising an entire operating system; while Apple managed a similar thing with their Classic environment, which would be what Microsoft would want to copy, virtualising on the level of VMWare is overkill, and adds more complexity than should be necessary (though it does provide some benefits as well).
If Vista were Microsoft's Copland, then they would have realized that it was going to be a failure, and taken the good technologies to add to their existing products. Instead, they realized that it was going to be a failure, and so restricted many technologies (e.g. DirectX 10) to Vista in order to force adoption.
It's obvious Microsoft knew that people wouldn't want Vista in the quantities that they needed; their solution, instead of fixing it, was to force it on people instead. Sad.
Videotron in Quebec offered a similar service; even if you were on their 600 kbit connection, you could buy, for $5, access to their 10mb connection for 48 hours. Great for people who torrent, but rarely, or who legitimately download large files (Fedora ISOs?). Pretty nice. Never used it myself, but great for grabbing those 'Complete season 2' torrents.
I worked for a company that did mobile data collection software, including actual survey design (flowing questions, ask this question based on this question's answer, filter these responses, ask this set of questions once for each child listed in previous questions, etc.).
This stuff is trivial to implement if you do it right, and all it takes is commodity Palm hardware (or PocketPC hardware running an emulation layer, or Windows tablets). It's trivial to do, syncs automatically, and can export all the data in a format easily used for generating whatever reports or correlations you want. The fact that the government is screwing this up (or rather, their contractor is) is just an example of not shopping around (or perhaps limiting their shopping to only American companies).
There's no reason that it should cost anywhere as much as it does, unless they're hiring way too many people (or can't manage the travelling salesperson problem). It's just a mismanaged government cock-up, is all.
Except they don't go to everyone's house at a time when people are likely to be home (necessarily). My mail sure as heck doesn't come when I'm home, and only when I was working graveyard shifts in the past has that ever happened. The problem with censuses is that they're not just going door-to-door, it's going door-to-door and asking questions of people over the age of 18 who live there. That's why they need census-takers.
I think the worst part of it is that the systems that are rejecting mail (because they're still configured to use ORDB) are the ones that are the least-maintained, and quite possibly completely forgotten about - and therefore are least likely to be noticed quickly or fixed intentionally.
That said, if you're that crappy of a sysadmin, you deserve a wake-up call. It's just too bad that other people have to suffer for you to learn to do your job properly.
Another example I've seen on several occasions is a system Apache (compiled against a system openssl) loading a custom PHP compile (compiled against a local openssl from /usr/local). Suddenly you have two similar-but-different versions of SSL. I've seen situations where this breaks completely, and situations where the linker figures out (at run-time) that you've already got libssl loaded, and things break unexpectedly.
This is further exacerbated when dependencies get more complicated. Apache-SSL with SSL-enabled PHP loading MySQL and Postgres compiled with SSL support gives you four different points where the wrong version could be expected/required. Similarly, practically everything you ever compile links against zlib, or links against something that does. Lots of points of failure.
This is why, IMHO, it's important to use a system which allows you to simply and easily update important libraries in a way that doesn't break existing applications (or breaks them predictably, in every case, so you know what will need fixing). This is one thing I don't trust RHEL for; Debian, on the other hand, tends to handle this well (and presumably, by extension, Ubuntu as well).
...but it's real challange lies ahead: convincing folks to stop buying DVDs and DVD players (which can be had for thirty dollars) and buy Blu-Ray discs and players... This is a task that electronics retailers (such as Best Buy) are in a real position to do with side-by-side demonstrations. Heck, I was in a Future Shop on Boxing Day and saw two identical televisions - identical except that one was the 1080i model, and one was 1080p - and I could tell the difference. It was subtle, but it was there. Showing someone a 1080p Blu-Ray feature next to the 480p DVD feature on the same television is going to be a pretty convincing show.The real trick is going to be getting the same content on both TVs, despite different sources. Perhaps downsamping the HD version, then letting the TV upscale it, would be a demonstration? Hard to say. Still, that would make a lot of sales.
80. (1) Subject to subsection (2), the act of reproducing all or any substantial part of
(a) a musical work embodied in a sound recording,
(b) a performer's performance of a musical work embodied in a sound recording, or
(c) a sound recording in which a musical work, or a performer's performance of a musical work, is embodied
onto an audio recording medium for the private use of the person who makes the copy does not constitute an infringement of the copyright in the musical work, the performer's performance or the sound recording. Subsection 2 disclaims this privilege for renting, selling, or performing, as well as distribution. Thus, it is legal to make a copy of a friend's CD for your personal use, but not legal for your friend to make a copy of his CD for your personal use. Opinion has varied, but the general consensus (including that of the courts, IIRC) is that internet filesharing involves the recipient making the copy, which thus falls under subsection 1 but is not excluded by subsection 2.
Note that this section of the act applies specifically to audio recordings, and specifically to 'an audio recording medium', but since audio can be recorded onto pretty much any digital medium, I doubt that that qualifier makes that much of a difference.
The biggest problem with targeting Linux, be it for games or any other commercial program, is ambiguity and the 'moving target' nature of Linux.
Ambiguity: How do you support Linux? You can't, really. What you have to do (in a practical sense) is support a distribution of Linux - for example, Fedora or Ubuntu. But then what of all the others? For every grateful Ubuntu user, there's going to be an irate Gentoo user who complains that his system isn't 'supported' (replace Ubuntu and Gentoo with any two differing distros). How do you support Linux, when 'Linux' is such a general term, and the variations can be so different?
Moving Target: What do you support? FC5? 6? 7? 9? The latest-and-greatest? Two years' worth? The last two versions? This gets especially complicated if they try to support more than one distribution. Do you target the latest two releases of Ubuntu, and the last three of Fedora? The latest two of each? What if Ubuntu releases faster? What if it has more 'latest and greatest' support (libraries, Xorg, etc.). What about drivers? Will these distros work properly with the included drivers? with binary drivers? will the game work properly with both?
How do you deal with support? Do you train your support monkeys on Windows, then run them through a six-week course on Fedoras 5 through 9, and the last three Ubuntus? What if the users are using an older Ubuntu that isn't support (but on which it should work)? What if a user has problems with the stock (open-source) NV driver? Do you recommend the closed-source one? What if they don't want to use that one, for whatever reason? What if they use it and then upgrade their kernel and it stops working? More likely, what if the system upgrades it for them?
What about DirectX? It doesn't port. You'd have to rewrite with OpenGL, OpenAL, rewrite your networking code, your 2D acceleration code, image handling, surfaces, media playback... or I suppose you could pay more to license Crossover's tech, similar to the move EA made for Mac games... but that increases your costs as well. You'd have to replace all of your Win32 API code (simple, common stuff like opening files, etc.) with cross-platform wrapper functions or #define statements. You'd have to test on both platforms.
Can it be done? Of course! Blizzard does it. If you inspect the Blizzard binary, you find a collection of strings, including 'Win95', 'Win98', 'Win2K', 'WinME', 'WinXP', 'MacOS9', 'MacOSX', and 'Linux'. Interesting. But is it worth it for most companies to hire programmers to write cross-platform code? Or is it just easier to target the large, stable, reliable, stationary target that is Windows, and leave the 2% gain that a Linux version might provide?
Don't forget, companies have existed to bring games to Linux. They failed. There's a reason.