1) Consolidate and halve the number of pref panels. There's too many, they're all over the place and they contain advanced & seldom used features mixed in with the common features. Throw that crap out of the window and pursue something more minimalist and therefore easier to use. If Apple (and to some extent GNOME) can do it, then so can KDE.
2) Work with GNOME, Trolltech and Free Desktop and produce a common widget theme engine. I don't care if an app runs QT or GTK, I don't care if it's part of KDE or GNOME. I do care that the average Linux desktop looks severely schizophrenic and unpredictable from one app to the next.
What killed Palm for me
on
Palm's Mistakes
·
· Score: 2, Interesting
Was the lack of bluetooth and wifi in the same device. I wanted my next PDA (after my Palm Vx) to be able to do a little web browsing and be able to share contact numbers with my phone. The various Palm devices just stunk - either offering wifi or bluetooth but not both. Of course I could have purchased some SD wifi dongle, but it's too bad if you want to use your device with a memory expansion. Since there was nothing like it (two years back) I got an iPaq instead.
Now it has to be said that PocketPCs stink as PDAs, but they great all-rounders. Whereas Palm Pilots are great PDAs but just awful for anything but PIM functionality. I guess that Palm's problem was that the world started expecting more than PIM functionality from their devices and they couldn't deliver.
One would hope that they would still follow through with their plans to run over Linux - it offers the opportunity to leapfrog CE - but somehow I doubt it. I wonder if MS didn't throw a lot of cash at them to throw the towel in on that front.
That isn't correct. I've been involved with two financial trading applications that used an.mdb file via JET / MDAC to store accounts, positions and other data. For what it was in its heyday, it was a great database. It may suck compare to modern servers, but it works well within its limitations.
Nowadays Win32 apps that require a data engine have a choice of two - trusty.mdb or MSDE. The latter ships as a 40Mb download, but it is to all intents and purposes MS SQL Server with some file and usage restrictions that mostly don't matter on the desktop. It's a smart move by Microsoft since it means SQL Server is shoe-in if an app's needs grow.
I'm quite a fan of PostgresSQL and I reckon with a little work it could be packaged like MSDE - a database engine without any of the other junk. The Win32 installer is pretty nice for v8.0. A redistributable would probably weight in at 5mb. It would be quite attractive for the same reasons MSDE is - use the PG engine today, upgrade to PGSQL (or even Oracle) running on Win32 / Linux tomorrow.
Unless every single app you connect to the DB contains trigger-like code and you don't expect your users to abuse or circumvent the trigger-like code, I fail to see why you would not want them.
As for stored procedures, I thought the whole point of them is that they are precompiled and live on the server side. Not only does this make them faster but you can change or modify the stored procedure without having to change the client code. Again, what's the point of not wanting them?
Is there any evidence to suggest that "just program it yourself" on the client side would be any more efficient? It seems to me that sending a large chunk of SQL over the wire, parsing / validating it, compiling it, and executing it must be for any sane DB slower than a stored proc.
Tor would be simple to block - the Chinese government could hook up modified versions Tor, compile a list of IP addresses in the "onion skin" and firewall them out. They could even run a bunch of phony clients, published from their own bogus servers and just sit and wait for the traffic to flow through them. A few bullets through the head for the worst "offenders" would pretty much curb the activity.
Even if MS Office supported opendocument (and it could), Microsoft could ensure that it was not the defacto format fairly easily by either not installing it by default, only shipping it with certain versions of MS Office, or even making it an additional download that the user has to go off and get. Which basically means that 95-99% of users never bother.
On top of that, I'm also sure they'd identify weaknesses in the specification and ensure that their.odt files are laced with extra namespaces & markup which made documents look terrible or broken unless you happened to be using MS Office to load and save them.
Other fun things they could do? Scary warnings before saving in.odt about "not everything can be saved if you use this format", half assed implementations of opendoc that don't support more esoteric features, and more besides.
No, it's a case of 99 cents for an track or $9.99 for an album is nearly the same price as to buy a physical CD. I can buy a new CD from Amazon.com for $10.99 so by going iTMS I'm saving a massive.99 for which I sacrifice sound quality, restrict my rights to copy that music and obliterate any chance of legally selling that music on.
Meanwhile, the record company saves on replication, storage, shipping, distribution, returns, copy protection fees and more besides. It would not surprise me at all if they make more money off digital music since all their overheads are slashed.
The fact is that the price is already at the limit. Given the economies of scale and competitive pressure and the aforementioned loss of rights, that price should be a hell of a lot lower. I'm not talking allofmp3 low, but if the retailer, studio and (horror!) the artist can't make money out of 99c or less for a track then there is something horribly wrong with their business.
99 cents for a track is hardly a bargain when to purchase a full CD costs you 75% - but without any of the rights that go along with owning a physical CD such as being to sell it on.
And of course for non-chart music, you could probably pick up the actual CD for less just by scouring eBay, zShops or even a sale in a regular bricks & mortar store.
I believe some countries allow you to use your rapid transit card to make small purchases. In addition of swiping your card to be allowed through a gate you can buy a bar of chocolate or a newspaper or other small transactions. Apparently London is piloting doing such a thing with their Oyster card.
It makes sense that if you have a card which is acting like pocket change to allow this. You deplete the credit and then you top it up. You can only spend as much as you have on the card so it has a natural cutoff. Since you buy the card with cash from a machine, the card is effectively acting like semi-anonymous currency.
It doesn't make much sense to do the same with a credit card, unless the credit card imposes a hard limit on what you can spend in such a manner. And I don't mean per item - I mean total that you deplete and must be topped up either by you or a preset top up. Otherwise what's to stop someone reading your RFID and making their own purchases by spoofing yours?
It doesn't really make sense to even embed the RFID into the credit card anyway. Are Mastercard going to be happy with reissuing cards to hundreds of people for the sake of thieves leeching $10 a day off them? How does a customer or Mastercard even spot suspicious transactions for tiny items anyway until the statement arrives?
It seems smarter for the RFID to be on separate card - to be more like a gift card that can be topped up at the discretion of main card holder. These could be sold anywhere and it would be easy for someone to buy a couple of them and set them up with their main account. Then if someone steals one, you simply don't top it up anymore. This would of course require Mastercard or whoever to stop gouging owners of these cards by charging a monthly "administration fee", but if they wanted to see the scheme work, they'd waive it.
I'm more comfortable with emacs than vi. I know a handful commands in vi which is sufficient to deal with it when I'm forced to but emacs strikes me as the more "normal" of the two. Even so, I find emacs to be absolutely horrible to configure properly and I just hate trying to get the bloody thing to indent C++ the way I like it. The entire configuration of emacs is a total mess in fact, almost requiring you to learn to program lisp. IMHO Xemacs is a better emacs than emacs is because the prefs and configuration is simpler.
My current choice of editor when I absolutely positively have to use a text window is jed (a tiny emacs clone) since it's considerably faster to load. And failing that I'd rather use a GUI editor anyway. I'm not averse to dedicated editors - I like Jedit quite a lot, but frankly I'd take an IDE or a GUI editor over emacs / vi + make + command line anyday.
Firefox / Thunderbird are certainly cleaner than the suite, but you lose some benefits of integration. For example, the suite allows you to middle click on a link in an email and open it as a new browser tab. Or you can edit the page you're viewing from the menu. Or create a single wallet which holds passwords from your browser and email app. Or have a disk and memory footprint of one app instead of many.
I admit you could probably live without some of these things, but then again they all add up. I know that I really miss the middle-click behaviour on emails when using Firefox and Thunderbird.
How does running so far in so many minutes indicate whether you're going to withstand the forces encountered during liftoff? If the answer is, "it doesn't", then why bother at all? They could just be stuck in a centrifuge and be done with it.
I think though a lot of this is legacy code that will eventually be made cleaner for the sake of making the app easier to maintain.
Sadly it's not legacy. Microsoft's brand new and shiny application blocks contain PInvokes. Any app written off of them will become instantly incompatible with Mono on other platforms. I haven't checked but I have my doubts that the MS licence would even permit the application block code running or being ported to non-MS platforms. I suppose it would be possible for Mono to special-case certain PInvokes if they're used in well-defined ways such as ABs but I fear that this is not likely to be fool-proof.
I would like to think that there would be more pressure to make apps cross-platform but I don't think it is happening. I work for a major finance company which is doing lots of.NET stuff. I raised concerns about using the MS Enterprise Library because it might not work with mono and I was told it wasn't on the company's radar. Their concern is coding stuff now on time and on budget, not worrying about how much it will cost to port it to another platform later. This despite the huge amount of Java code they have which demonstrates what a good idea cross-platform code is. I think this attitude is representative. Managers with a budget and a deadline don't care beyond the end of their own noses.
Worse is that Mono is doing itself no favours by the way it is being propogated. Mono offers an alternative development stack, but who bothers with that? It's impossible to develop to it with on Win32 without dropping to the command line. Meanwhile MS offers Developer Studio with wizards, syntax highlighting, form designers and whatever.
MonoDevelop could alleviate some of this but AFAIK it doesn't even run on Win32 which somewhat contradicts the whole point of Mono. I've never even gotten it to run on Fedora despite trying very hard. The only other IDE that seems to fit the bill is #Develop and that doesn't work on Linux. So there is a gulf between Win32 and Linux which wouldn't even exist in Java-land. There is nothing comparable to Eclipse by a long stretch.
If Mono or others can't even produce cross-platform IDEs, I don't hold out much hope that others will make the effort. I lay the blame squarely with Microsoft here. They could have set the default policy of.NET to ban PInvoke & COM controls but they didn't. They could have set coding & quality guidelines that banned PInvoke and COM but they didn't. Instead they decided to throw the switches and in the process ensure that.NET is heavily Win32 dependent. The water is so cloudy that it will take years if ever to settle.
On top of that.NET is a nebulous term for the CLR,.NET Framework and anything else they feel like including under it. Microsoft are in the position to change the definition or toss in other assemblies which are by their nature Win32 dependent such as ASP.NET.
I truly believe that this was their intention all along - to allude to being another cross-platform solution such as Java but being so infested with Win32 specific things that this is a complete lie.
I've always wondered about the fitness requirement. You can understand that you want someone who is medically fit for a several reasons a) that they don't drop (or float) dead, b) they weigh less, c) they may consume oxygen more efficiently. But I don't really understand how some artificial artifice such as running so many miles in so many minutes necessarily qualifies or disqualifies someone on that basis.
After all, I'm pretty sure that any horse jockey qualifies quite easily but that doesn't mean they're the best man for the job.
If that's the rationale, I think midgets should be sent up in space. Not only do they weigh less, savings can be made by miniaturizing their habitat and food / oxygen requirements.
The security of ActiveX is no worse than any other natively executed piece of code. The problem is not in the controls themselves but the way MS has traditionally encouraged sites to use them and "trained" users to automatically download and install them.
A benign but exploitable control signed by MS (for example) can be forced on a user by a malicious site and then used to compromise their machine. i.e. the trust model is completely broken.
Microsoft have been increasingly deemphasizing ActiveX because of all the problems with it. I think that IE7 is going to be extremely restrictive of what ActiveX controls can do. ActiveX controls are bad news and even MS know it.
So what's going to replace it? I expect to see XAML and.NET being pitched as the alternative solution for sites that want interactive content. In theory a.NET application could run in a sandbox mode just like Java and still provide useful functionality but it really depends what security policy MS set and how the secure the design and implementation are before knowing that.
Sadly,.NET is no Windows killer. You just have to look at enough.NET apps to realise that many will only run on Windows. I'm know there are Mono /.NET apps out there that are clean but many apps that use PInvoke or COM interop to function. These are doomed to never work with Mono. You can bet that this inclues many apps ported from VB6 to.NET.
On top of that Microsoft is pushing things called Application Blocks (ABs) which a useful bits of functionality such as logging and caching. There is already an enterprise library version of the ABs (backend stuff mostly) and MS is poised to release ABs for UI development for.NET 2.0. In theory this sounds like a great idea, but you just have to grep the source of these ABs for PInvoke and you realise they're infested with Win32 calls. So anyone who uses an AB may unwittingly be tying themselves to Win32.
I suppose in theory, the ABs could be fixed to remove the calls - calls to high performance timers and so on - but where is the pressure going to be to do that? Microsoft most certainly won't care to do it, and I suspect there will be all kinds of rules to prevent developers doing it.
So at the end of the day whether.NET is allegedly cross-platform, the reality is that it isn't. Not while MS continue to push and enable native calls by default.
SOH CAH TOA. SOH (Sine(x) = Opposite / Hypotenuse, Cos(x) = Adjacent / Hypotenuse, Tan(x) = Opposite / Adjacent where x is an angle of a right angled triangle)
Concerning reported incidents of whiplash, rheumatism, RSI and other injuries (limbs hitting chairs, relatives etc.) that this system induces in children.
The operative phrase is "most likely". You're throwing a big pile of money to buy something which isn't going anywhere. It will still be there in a week, two weeks and six months from now. The difference is that it will prove itself and some games might actually turn up that justify getting it.
It isn't valid to compare it to an iPod since an iPod Nano plays all your old music. It remains to be seen what backwards compatibility the XBox 360 has.
So why take the risk? You say MS & Sony would correct major flaws, but if the XBox 360 turns out to not play half your XBox games, or the core version doesn't play them at all. Or XBox Live goes DOA under the strain. Or none of the games support HD TV. Do you think MS are going to give you a refund? Even Sony didn't exactly bend over backwards to fix dead pixels in the PSP.
Um, because they will be having fun with their new console for those 4 or 5 months while you "gauge the scene."
Possibly. More likely they'll be desperately trying to have fun with handful of mediocre titles for that 4 or 5 months with barely a trickle of new releases. On top of that if they're extra unlucky they'll discover they're the proud owner of a box containing serious flaws. All for the sake of "being first" and paying over the odds.
Kinda like the guys who actually go out and get girls while people like you stand around trying to "gauge the scene."
The mentality of owning something first when its overhyped, unproven, expensive and has a dearth of games strikes me as very peculiar.
Why does anyone do it? What's wrong with waiting 4 or 5 months to gauge the scene? At that point the prices might have lowered a little, the hype will have been replaced with more level headed criticism, and there will certainly more games.
I just don't understand why anyone would do it. I certainly don't understand why on November 22nd / 23rd the news will be filled with clips of losers queuing up and streaming into stores to buy a console at midnight.
I should say before someone else does that iTunes 5.0 has dumped brushed metal, but it's still a slightly shaded gunmetal grey that serves the same purpose.
Slashdot Mirror
2) Work with GNOME, Trolltech and Free Desktop and produce a common widget theme engine. I don't care if an app runs QT or GTK, I don't care if it's part of KDE or GNOME. I do care that the average Linux desktop looks severely schizophrenic and unpredictable from one app to the next.
Now it has to be said that PocketPCs stink as PDAs, but they great all-rounders. Whereas Palm Pilots are great PDAs but just awful for anything but PIM functionality. I guess that Palm's problem was that the world started expecting more than PIM functionality from their devices and they couldn't deliver.
One would hope that they would still follow through with their plans to run over Linux - it offers the opportunity to leapfrog CE - but somehow I doubt it. I wonder if MS didn't throw a lot of cash at them to throw the towel in on that front.
Nowadays Win32 apps that require a data engine have a choice of two - trusty .mdb or MSDE. The latter ships as a 40Mb download, but it is to all intents and purposes MS SQL Server with some file and usage restrictions that mostly don't matter on the desktop. It's a smart move by Microsoft since it means SQL Server is shoe-in if an app's needs grow.
I'm quite a fan of PostgresSQL and I reckon with a little work it could be packaged like MSDE - a database engine without any of the other junk. The Win32 installer is pretty nice for v8.0. A redistributable would probably weight in at 5mb. It would be quite attractive for the same reasons MSDE is - use the PG engine today, upgrade to PGSQL (or even Oracle) running on Win32 / Linux tomorrow.
As for stored procedures, I thought the whole point of them is that they are precompiled and live on the server side. Not only does this make them faster but you can change or modify the stored procedure without having to change the client code. Again, what's the point of not wanting them?
Is there any evidence to suggest that "just program it yourself" on the client side would be any more efficient? It seems to me that sending a large chunk of SQL over the wire, parsing / validating it, compiling it, and executing it must be for any sane DB slower than a stored proc.
Tor would be simple to block - the Chinese government could hook up modified versions Tor, compile a list of IP addresses in the "onion skin" and firewall them out. They could even run a bunch of phony clients, published from their own bogus servers and just sit and wait for the traffic to flow through them. A few bullets through the head for the worst "offenders" would pretty much curb the activity.
Romanes eunt domus!
I don't know about anyone else but I think I just soiled myself with excitement.
On top of that, I'm also sure they'd identify weaknesses in the specification and ensure that their
Other fun things they could do? Scary warnings before saving in
Meanwhile, the record company saves on replication, storage, shipping, distribution, returns, copy protection fees and more besides. It would not surprise me at all if they make more money off digital music since all their overheads are slashed.
The fact is that the price is already at the limit. Given the economies of scale and competitive pressure and the aforementioned loss of rights, that price should be a hell of a lot lower. I'm not talking allofmp3 low, but if the retailer, studio and (horror!) the artist can't make money out of 99c or less for a track then there is something horribly wrong with their business.
And of course for non-chart music, you could probably pick up the actual CD for less just by scouring eBay, zShops or even a sale in a regular bricks & mortar store.
Grobot looks like a gnome. Krobot looks like a troll.
It makes sense that if you have a card which is acting like pocket change to allow this. You deplete the credit and then you top it up. You can only spend as much as you have on the card so it has a natural cutoff. Since you buy the card with cash from a machine, the card is effectively acting like semi-anonymous currency.
It doesn't make much sense to do the same with a credit card, unless the credit card imposes a hard limit on what you can spend in such a manner. And I don't mean per item - I mean total that you deplete and must be topped up either by you or a preset top up. Otherwise what's to stop someone reading your RFID and making their own purchases by spoofing yours?
It doesn't really make sense to even embed the RFID into the credit card anyway. Are Mastercard going to be happy with reissuing cards to hundreds of people for the sake of thieves leeching $10 a day off them? How does a customer or Mastercard even spot suspicious transactions for tiny items anyway until the statement arrives?
It seems smarter for the RFID to be on separate card - to be more like a gift card that can be topped up at the discretion of main card holder. These could be sold anywhere and it would be easy for someone to buy a couple of them and set them up with their main account. Then if someone steals one, you simply don't top it up anymore. This would of course require Mastercard or whoever to stop gouging owners of these cards by charging a monthly "administration fee", but if they wanted to see the scheme work, they'd waive it.
My current choice of editor when I absolutely positively have to use a text window is jed (a tiny emacs clone) since it's considerably faster to load. And failing that I'd rather use a GUI editor anyway. I'm not averse to dedicated editors - I like Jedit quite a lot, but frankly I'd take an IDE or a GUI editor over emacs / vi + make + command line anyday.
I admit you could probably live without some of these things, but then again they all add up. I know that I really miss the middle-click behaviour on emails when using Firefox and Thunderbird.
How does running so far in so many minutes indicate whether you're going to withstand the forces encountered during liftoff? If the answer is, "it doesn't", then why bother at all? They could just be stuck in a centrifuge and be done with it.
Sadly it's not legacy. Microsoft's brand new and shiny application blocks contain PInvokes. Any app written off of them will become instantly incompatible with Mono on other platforms. I haven't checked but I have my doubts that the MS licence would even permit the application block code running or being ported to non-MS platforms. I suppose it would be possible for Mono to special-case certain PInvokes if they're used in well-defined ways such as ABs but I fear that this is not likely to be fool-proof.
I would like to think that there would be more pressure to make apps cross-platform but I don't think it is happening. I work for a major finance company which is doing lots of .NET stuff. I raised concerns about using the MS Enterprise Library because it might not work with mono and I was told it wasn't on the company's radar. Their concern is coding stuff now on time and on budget, not worrying about how much it will cost to port it to another platform later. This despite the huge amount of Java code they have which demonstrates what a good idea cross-platform code is. I think this attitude is representative. Managers with a budget and a deadline don't care beyond the end of their own noses.
Worse is that Mono is doing itself no favours by the way it is being propogated. Mono offers an alternative development stack, but who bothers with that? It's impossible to develop to it with on Win32 without dropping to the command line. Meanwhile MS offers Developer Studio with wizards, syntax highlighting, form designers and whatever.
MonoDevelop could alleviate some of this but AFAIK it doesn't even run on Win32 which somewhat contradicts the whole point of Mono. I've never even gotten it to run on Fedora despite trying very hard. The only other IDE that seems to fit the bill is #Develop and that doesn't work on Linux. So there is a gulf between Win32 and Linux which wouldn't even exist in Java-land. There is nothing comparable to Eclipse by a long stretch.
If Mono or others can't even produce cross-platform IDEs, I don't hold out much hope that others will make the effort. I lay the blame squarely with Microsoft here. They could have set the default policy of .NET to ban PInvoke & COM controls but they didn't. They could have set coding & quality guidelines that banned PInvoke and COM but they didn't. Instead they decided to throw the switches and in the process ensure that .NET is heavily Win32 dependent. The water is so cloudy that it will take years if ever to settle.
On top of that .NET is a nebulous term for the CLR, .NET Framework and anything else they feel like including under it. Microsoft are in the position to change the definition or toss in other assemblies which are by their nature Win32 dependent such as ASP.NET.
I truly believe that this was their intention all along - to allude to being another cross-platform solution such as Java but being so infested with Win32 specific things that this is a complete lie.
After all, I'm pretty sure that any horse jockey qualifies quite easily but that doesn't mean they're the best man for the job.
If that's the rationale, I think midgets should be sent up in space. Not only do they weigh less, savings can be made by miniaturizing their habitat and food / oxygen requirements.
A benign but exploitable control signed by MS (for example) can be forced on a user by a malicious site and then used to compromise their machine. i.e. the trust model is completely broken.
Microsoft have been increasingly deemphasizing ActiveX because of all the problems with it. I think that IE7 is going to be extremely restrictive of what ActiveX controls can do. ActiveX controls are bad news and even MS know it.
So what's going to replace it? I expect to see XAML and .NET being pitched as the alternative solution for sites that want interactive content. In theory a .NET application could run in a sandbox mode just like Java and still provide useful functionality but it really depends what security policy MS set and how the secure the design and implementation are before knowing that.
On top of that Microsoft is pushing things called Application Blocks (ABs) which a useful bits of functionality such as logging and caching. There is already an enterprise library version of the ABs (backend stuff mostly) and MS is poised to release ABs for UI development for .NET 2.0. In theory this sounds like a great idea, but you just have to grep the source of these ABs for PInvoke and you realise they're infested with Win32 calls. So anyone who uses an AB may unwittingly be tying themselves to Win32.
I suppose in theory, the ABs could be fixed to remove the calls - calls to high performance timers and so on - but where is the pressure going to be to do that? Microsoft most certainly won't care to do it, and I suspect there will be all kinds of rules to prevent developers doing it.
So at the end of the day whether .NET is allegedly cross-platform, the reality is that it isn't. Not while MS continue to push and enable native calls by default.
Remember them and trigonometry is a doddle.
Concerning reported incidents of whiplash, rheumatism, RSI and other injuries (limbs hitting chairs, relatives etc.) that this system induces in children.
It isn't valid to compare it to an iPod since an iPod Nano plays all your old music. It remains to be seen what backwards compatibility the XBox 360 has.
So why take the risk? You say MS & Sony would correct major flaws, but if the XBox 360 turns out to not play half your XBox games, or the core version doesn't play them at all. Or XBox Live goes DOA under the strain. Or none of the games support HD TV. Do you think MS are going to give you a refund? Even Sony didn't exactly bend over backwards to fix dead pixels in the PSP.
Possibly. More likely they'll be desperately trying to have fun with handful of mediocre titles for that 4 or 5 months with barely a trickle of new releases. On top of that if they're extra unlucky they'll discover they're the proud owner of a box containing serious flaws. All for the sake of "being first" and paying over the odds.
Kinda like the guys who actually go out and get girls while people like you stand around trying to "gauge the scene."
That comparison is both sad and ironic.
Why does anyone do it? What's wrong with waiting 4 or 5 months to gauge the scene? At that point the prices might have lowered a little, the hype will have been replaced with more level headed criticism, and there will certainly more games.
I just don't understand why anyone would do it. I certainly don't understand why on November 22nd / 23rd the news will be filled with clips of losers queuing up and streaming into stores to buy a console at midnight.
I should say before someone else does that iTunes 5.0 has dumped brushed metal, but it's still a slightly shaded gunmetal grey that serves the same purpose.