Great, but I didn't have to visit an xp-laptop.net site to get XP working on a laptop - it just did.
The problem with Linux is that because there is no binary driver interface and driver model common to all dists, the likes of Intel etc. will not release drivers for Linux until they're old and crusty.
The dist makers need to sit around the table with the driver writers and work out a dist-neutral binary API for a common class of devices - network cards, graphics cards, sound cards, wireless joysticks and so on. It could sit above the kernel so it wouldn't tie the kernel (or Linus) to supporting the API. It would be the dist maker's job to ensure the API functioned for the 2.6.x seriers or whatever, at which point they could review the API and enhance it for the next release and so on.
The Discovery channel in the UK frequently uses a British narrator even for US shows - Mythbusters, American Chopper etc. You're either hearing the UK version or the Australians do something similar.
It's nothing new. The Horizon / Nova programmes were narrated in UK / US versions too.
Well Sun has partially lifted the covers of Sun, and there are open and licenced implementations of the JVM for a whole range of devices. So the situation really isn't quite as similar.
Now I don't think it would be a bad thing if Sun did open source Java. In fact they probably must if they intend to remain viable in the cacophony surrounding.NET / Mono on one side and other languages like PHP / Python / Ruby on the other. None of them is a real threat yet but its only a matter of time.
Jesus, what a waste of money! You could buy a normal CPU and still have enough money left over for another PC (or something nice of your choice) instead of this glorified griddle.
When dual core prices start coinciding with reality, there might be a point to buy one, but not at the moment.
And most server side code spends its life serving requests and talking to back end business objects / databases. This means there is a lot of built-in latency with most of the code sitting around waiting for something to happen.
That's the reason in the first place for Java to be attractive. It doesn't have to be as fast as C++. What's more important is that it doesn't crash, has an extremely powerful set of APIs for doing all kinds of enterprisey things and runs just about everywhere.
There's no doubt either that you could do the same in Perl, Python or Ruby but speed is generally the least of your issues. I'd rather have code that is readable and that it has the tools for the job it is doing. If it works already in Java I see zero gain in moving it to another language, especially as Java already has fantastically good web serving functionality with numerous commercial and non-commercial standards implementations to choose from.
OpenGL is a graphics protocol. Mesa is the implementation of it in all but name. Now what about the spatial sound, multimedia, game controllers, screen resolution negotiation and everything else that DirectX provides?
Yes, libsdl does some of the basics, but it's a stepping off point, not a solution. It would be ironic indeed if winelib gets such a good DirectX implementation that its easier for authors to port to that than code from sdl which is missing large chunks of functionality.
Of course some of these issues might be solved if the dists became more game friendly. Hell, most dists don't even ship with an accelerated graphics driver or make it easy for someone to go off and get one either. And game controllers? Well that's a kernel rebuild, assuming your controller is even supported.
My point in case it's lost, is that no one has sat down and agreed on things that would make Linux a viable gaming platform. At the end of the day it has all the requisite bits, but the current atmosphere basically says to any gamer - "you jump through all these hoops" and to the game author - "you write a big massive install script that fixes all this mess". That's hardly conducive to take up or good will on either side.
All the big ISPs have been after spammers for quite a while now. I believe that AOL is owed a few million by that bankrupt spammer who featured in another/. story quite recently.
Not only that but some stores advertise a product as $99.99 (*) and then a explanation in small print says "after mail in rebate". So it actually costs $149.99 unless you jump through all the hoops required to get the difference refunded. I'm an occasional visitor to the US so I can't get a rebate at all and I was caught out by this once. To me this kind of deceptive pricing is tantamount to lying. If the store lies about the price, what does that say about them?
Nowadays I explicitly avoid anything with rebate written on it. I'm sure many US residents do the same.
Now, if only the tax was included in the price also...
Win32S was the Win32 API but it was basically brain dead under the surface and had lots of caveats. Mostly it just mapped the calls onto their 16 bit counterparts and suffered from the same limitations with regards to heap space etc.
But WINE is much more powerful - calls might be mapped onto their Linux equivalents but mostly this is possible without caveats since the two operating systems share similar functionality - 32bits (or more), threads, IPC, TCP/IP, virtual memory, long file names etc. The issue for WINE is that Win32 is a nebulous term for an ever changing set of APIs, some of which are barely documented.
They've already implemented enough that WINE can run MS Office, and if you had the MS Office source you could therefore almost certainly link it to winelib.
I reckon that your biggest headache if you were to port Office would be the build system and the compiler tools. Second place might go to getting OLE working. Third place would go to supporting the Linux way of specifying paths, config settings, permissions, look & feel. Other than that, I really believe it would pretty straightforward - a slog to be sure through the various compiler errors, but very little technical problems. In fact I believe that Wordpefect for Linux was basically the Win32 version built and linked to winelib.
Both KDE and GNOME are close enough to Win32 that aside from the widget appearance the position of menus and so forth is actually very similar between Linux apps and Win32. The UI wouldn't need much work except perhaps around the clipboard and printing.
It's not like the Mac where *everything* needs to be rewritten to match the Mac UI. Mac zealots went ballistic on a previous version of MS Office that dared to stray too far from the Mac L&F.
The cross-platform version of IE was basically compiled over a Win32 layer for Unix (a la WINE). Except the Win32 layer was called Wind/U and written by a company called Bristol Technology who licenced the code from Microsoft. Then Microsoft fucked them over, Bristol sued, lost, and that was the end of that.
IE for Unix was horrid anyway, but it demonstrate that there was absolutely no technical barrier to porting code to that platform. In fact I reckon it would take considerably less work to port Office to Linux (using WINE) that it woulde to port it to OS X.
Apple have hit upon the perfect subscription model - release frequent point releases (yes it is a point release) for $129 or so and pull the rug from older revisions as you do so.
People have no choice but to continue paying every year or so or they're left with a Mac that doesn't run any new software / hardware.
Actually that site was updated since the email so I assume it takes those suggestions into account.
As for loops, calculations etc. not being a proper measure - perhaps it doesn't matter much for wizards. But that's the thin end of the wedge. They're using it for the SQL database and no doubt would use it for other things too in time if left to their own devices.
As for SWT - I'm sure it can be made to run reasonably. Kaffe claims to run Eclipse though I shudder to think what the performance is like. I have a CVS snapshot of Kaffe on my box so maybe I'll try it. But the fact is that while SWT speeds up widgets, it doesn't do much outside of that. It's very easy to bog Eclipse down in the best of circumstances under Sun Java, so running it under an interpretter would be hell. The same goes for other SWT apps like Azureus which are doing intensive things outside of just showing a few buttons.
While its great to see gcj spurred on by Java encroaching into a critical Linux application, it doesn't mean that encroachment is desirable in any way. If they wanted to make parts of OO scriptable they could have chosen any number of open source engines that could have worked as well. For example Python or Ruby would fit the bill just as well.
Oh they use it alright. I've worked for companies before now that force you change the password with various rules such as no dupes, must used mixed case, digits etc. This is fine once every 3 months but some do it every month which results in mass annoyance since no one can remember a password when it changes that often. Thus the solution for myself and others was the old "increment by one" trick or to write it down or to recycle old passwords on a rotating basis. A per month password policy is actually less secure 3 month one for this very reason.
Linux can also enforce various rules through PAM and even warns you (in FC) when a password is guessable though I don't know if any dist actually mandates passwords based upon a strict set of rules.
Possibly, but gcj is not complete and suffers from its own problems. Additionally, it is much slower than the JRE from Sun. Look at the stats to see how various free and not so free runtimes perform. Note that the likes of Kaffe & GCJ run at a mere fraction of the runtimes from Sun & IBM.
KDE only superficially resembles Windows, such as through the IE 4.0 era "Active" desktop (which is blessedly configurable now) and other behaviours. Things like the control center are nothing like Windows and are an utter mess of so many options that its impossible (even as an expert) to use with any comfort. In fact trying to configure the UI or Konq or any other large chunk of KDE is a massive pain simply because there are so many pages, tabs, advanced dialogs to tweak every last facet of behaviour. I'm sure that's nice and all but lots of UIs manage on a lot less.
GNOME also lifts parts from here or there - the rounded bar at the top is very Mac-esque. Despite this, it reins in the influences so it never feels like they're tossing in "features" from every UI in existence. It feels more like a UI in its own right where the components integrate without overwhelming or overlapping. I have never felt confused by the control panel in GNOME because it doesn't mix the commonly used options up with advanced ones. This is in no small part to GNOME enforcing its HIG. Older versions used to be a crashy mess but the 2.x series has become incresingly stable and solid.
It might say some from a build and configuration perspective, but from an end user perspective, it's probably the opposite. KDE is a kitchen sink desktop with far too many settings, GNOME is spartan and clean. I know which one I'd put in front of newbies and it doesn't start with a K.
If you want never want to fall asleep after hitting the alarm, simply place it on the other side of the room so you have to get up. It's that simple really. No walking alarm clocks are required at any stage of the process.
Sadly that isn't as true as it might appear. While it's great that pure C# apps using common functionality will port, a hell of lot of real world apps won't.
Real world.NET applications are peppered with PInvokes, COM interop, MSSQL / IIS extensions and various other crap which makes the run badly or not at all on Mono. Even the best will in the world won't change this.
WINE might help a bit, but its too bad if you're on a non-x86 platform.
Even Microsoft don't give a damn about portable.NET. Witness their new Enterprise Library which they're pushing on developers. It contains several dozen Win32 calls right there in this common library. Any enterprise app that relies on it will be infected as a result.
I know that, but that doesn't mean that a 6 month old FC3 is going to work flawlessly on a chip that hasn't even appeared in channels yet, let alone in a Dell that doesn't exist, let alone for a user who bought the Dell in the first place, let alone support it any optimal fashion (e.g. support for Intel / AMD specific functionality).
Once Linux supports it properly (as in having been tested on production machines), and XP 64 appears and the likes of Dell produce a 64 bit machine then there might be a point for telling someone to get it. At that point the weight will shift into the 64-bit world and the market will take care of the rest. But at the moment there is little point.
Yes it does and I know it does. Where did I say different?
Now tell me which AMD64 version of Linux works out of the box with an Intel 64-bit processor. I'm sure both processors are mostly similar but they're not identical, that's for sure.
What's the point? A 64-bit Intel will do absolutely nothing more than a 32-bit Intel chip will do. Why? Because Windows XP, Linux and everything else hasn't the faintest idea what a 64-bit x86 Intel chip is. So everything will run in 32-bit mode until such time as someone produces an OS that takes advantage of it.
It's possible that Linux might be quicker off the mark to support the chip - you might even be able to patch it yourself with the right gcc & kernel - but since you said Dell you're really talking about XP. And XP isn't going to see support unless Microsoft produces another service pack to shore up the gulf of time that exists between now and their next release. Even if they do release SP3 with 64 bit goodness, you're still talking 6 months or more and the chances are that it will only offer token support in a limited number of places.
On top of that, buying unsupported bleeding edge hardware is always a bad proposition. Its expensive, doesn't do anything and will probably be obsolete by the time that something comes around to supporting it. It would have been as foolish to buy AMD64 back when it was released.
Bloggers who don't lock down their comments section deserve to be spammed. We're not talking rocket science here. A blog is just a forum where the topic has already been set.
If you invite responses, require that your users sign up before being able to post comments (or at least do some human trivial / computer hard task), ban html, ban certain links, throttle their comments to a few a day, use tools to bulk remove duff comments by ip address, keyword or user and generally make them look elsewhere for an easy mark.
It really should be that hard. There are dozens of open source bbs / mailing list apps which must already contain this kind of code already. Bloggers should be using blogging code which contains these safeguards rather than pushing the bandwidth onto Wikipedia.
Slashdot Mirror
The problem with Linux is that because there is no binary driver interface and driver model common to all dists, the likes of Intel etc. will not release drivers for Linux until they're old and crusty.
The dist makers need to sit around the table with the driver writers and work out a dist-neutral binary API for a common class of devices - network cards, graphics cards, sound cards, wireless joysticks and so on. It could sit above the kernel so it wouldn't tie the kernel (or Linus) to supporting the API. It would be the dist maker's job to ensure the API functioned for the 2.6.x seriers or whatever, at which point they could review the API and enhance it for the next release and so on.
It's nothing new. The Horizon / Nova programmes were narrated in UK / US versions too.
Now I don't think it would be a bad thing if Sun did open source Java. In fact they probably must if they intend to remain viable in the cacophony surrounding
When dual core prices start coinciding with reality, there might be a point to buy one, but not at the moment.
That's the reason in the first place for Java to be attractive. It doesn't have to be as fast as C++. What's more important is that it doesn't crash, has an extremely powerful set of APIs for doing all kinds of enterprisey things and runs just about everywhere.
There's no doubt either that you could do the same in Perl, Python or Ruby but speed is generally the least of your issues. I'd rather have code that is readable and that it has the tools for the job it is doing. If it works already in Java I see zero gain in moving it to another language, especially as Java already has fantastically good web serving functionality with numerous commercial and non-commercial standards implementations to choose from.
The platter employs string theory and rotates through 40 planes of reality.
Yes, libsdl does some of the basics, but it's a stepping off point, not a solution. It would be ironic indeed if winelib gets such a good DirectX implementation that its easier for authors to port to that than code from sdl which is missing large chunks of functionality.
Of course some of these issues might be solved if the dists became more game friendly. Hell, most dists don't even ship with an accelerated graphics driver or make it easy for someone to go off and get one either. And game controllers? Well that's a kernel rebuild, assuming your controller is even supported.
My point in case it's lost, is that no one has sat down and agreed on things that would make Linux a viable gaming platform. At the end of the day it has all the requisite bits, but the current atmosphere basically says to any gamer - "you jump through all these hoops" and to the game author - "you write a big massive install script that fixes all this mess". That's hardly conducive to take up or good will on either side.
All the big ISPs have been after spammers for quite a while now. I believe that AOL is owed a few million by that bankrupt spammer who featured in another /. story quite recently.
Nowadays I explicitly avoid anything with rebate written on it. I'm sure many US residents do the same.
Now, if only the tax was included in the price also...
But WINE is much more powerful - calls might be mapped onto their Linux equivalents but mostly this is possible without caveats since the two operating systems share similar functionality - 32bits (or more), threads, IPC, TCP/IP, virtual memory, long file names etc. The issue for WINE is that Win32 is a nebulous term for an ever changing set of APIs, some of which are barely documented.
They've already implemented enough that WINE can run MS Office, and if you had the MS Office source you could therefore almost certainly link it to winelib.
I reckon that your biggest headache if you were to port Office would be the build system and the compiler tools. Second place might go to getting OLE working. Third place would go to supporting the Linux way of specifying paths, config settings, permissions, look & feel. Other than that, I really believe it would pretty straightforward - a slog to be sure through the various compiler errors, but very little technical problems. In fact I believe that Wordpefect for Linux was basically the Win32 version built and linked to winelib.
Both KDE and GNOME are close enough to Win32 that aside from the widget appearance the position of menus and so forth is actually very similar between Linux apps and Win32. The UI wouldn't need much work except perhaps around the clipboard and printing.
It's not like the Mac where *everything* needs to be rewritten to match the Mac UI. Mac zealots went ballistic on a previous version of MS Office that dared to stray too far from the Mac L&F.
IE for Unix was horrid anyway, but it demonstrate that there was absolutely no technical barrier to porting code to that platform. In fact I reckon it would take considerably less work to port Office to Linux (using WINE) that it woulde to port it to OS X.
People have no choice but to continue paying every year or so or they're left with a Mac that doesn't run any new software / hardware.
As for loops, calculations etc. not being a proper measure - perhaps it doesn't matter much for wizards. But that's the thin end of the wedge. They're using it for the SQL database and no doubt would use it for other things too in time if left to their own devices.
As for SWT - I'm sure it can be made to run reasonably. Kaffe claims to run Eclipse though I shudder to think what the performance is like. I have a CVS snapshot of Kaffe on my box so maybe I'll try it. But the fact is that while SWT speeds up widgets, it doesn't do much outside of that. It's very easy to bog Eclipse down in the best of circumstances under Sun Java, so running it under an interpretter would be hell. The same goes for other SWT apps like Azureus which are doing intensive things outside of just showing a few buttons.
While its great to see gcj spurred on by Java encroaching into a critical Linux application, it doesn't mean that encroachment is desirable in any way. If they wanted to make parts of OO scriptable they could have chosen any number of open source engines that could have worked as well. For example Python or Ruby would fit the bill just as well.
Linux can also enforce various rules through PAM and even warns you (in FC) when a password is guessable though I don't know if any dist actually mandates passwords based upon a strict set of rules.
Possibly, but gcj is not complete and suffers from its own problems. Additionally, it is much slower than the JRE from Sun. Look at the stats to see how various free and not so free runtimes perform. Note that the likes of Kaffe & GCJ run at a mere fraction of the runtimes from Sun & IBM.
GNOME also lifts parts from here or there - the rounded bar at the top is very Mac-esque. Despite this, it reins in the influences so it never feels like they're tossing in "features" from every UI in existence. It feels more like a UI in its own right where the components integrate without overwhelming or overlapping. I have never felt confused by the control panel in GNOME because it doesn't mix the commonly used options up with advanced ones. This is in no small part to GNOME enforcing its HIG. Older versions used to be a crashy mess but the 2.x series has become incresingly stable and solid.
It might say some from a build and configuration perspective, but from an end user perspective, it's probably the opposite. KDE is a kitchen sink desktop with far too many settings, GNOME is spartan and clean. I know which one I'd put in front of newbies and it doesn't start with a K.
Well Skype 1.2 is official. And yes you pay for the service - 30 euros a year for a number and voicemail.
Or wait until it is night / dark / light etc.
If you want never want to fall asleep after hitting the alarm, simply place it on the other side of the room so you have to get up. It's that simple really. No walking alarm clocks are required at any stage of the process.
Real world .NET applications are peppered with PInvokes, COM interop, MSSQL / IIS extensions and various other crap which makes the run badly or not at all on Mono. Even the best will in the world won't change this.
WINE might help a bit, but its too bad if you're on a non-x86 platform.
Even Microsoft don't give a damn about portable .NET. Witness their new Enterprise Library which they're pushing on developers. It contains several dozen Win32 calls right there in this common library. Any enterprise app that relies on it will be infected as a result.
Once Linux supports it properly (as in having been tested on production machines), and XP 64 appears and the likes of Dell produce a 64 bit machine then there might be a point for telling someone to get it. At that point the weight will shift into the 64-bit world and the market will take care of the rest. But at the moment there is little point.
Now tell me which AMD64 version of Linux works out of the box with an Intel 64-bit processor. I'm sure both processors are mostly similar but they're not identical, that's for sure.
It's possible that Linux might be quicker off the mark to support the chip - you might even be able to patch it yourself with the right gcc & kernel - but since you said Dell you're really talking about XP. And XP isn't going to see support unless Microsoft produces another service pack to shore up the gulf of time that exists between now and their next release. Even if they do release SP3 with 64 bit goodness, you're still talking 6 months or more and the chances are that it will only offer token support in a limited number of places.
On top of that, buying unsupported bleeding edge hardware is always a bad proposition. Its expensive, doesn't do anything and will probably be obsolete by the time that something comes around to supporting it. It would have been as foolish to buy AMD64 back when it was released.
If you invite responses, require that your users sign up before being able to post comments (or at least do some human trivial / computer hard task), ban html, ban certain links, throttle their comments to a few a day, use tools to bulk remove duff comments by ip address, keyword or user and generally make them look elsewhere for an easy mark.
It really should be that hard. There are dozens of open source bbs / mailing list apps which must already contain this kind of code already. Bloggers should be using blogging code which contains these safeguards rather than pushing the bandwidth onto Wikipedia.