I don't agree. I was slightly wrong in saying no licence is required - it is covered by your main household licence no matter where the device is situated. Presumably most people have a TV anyway. But in any case a phone could be programmed to only pick up satellite channels and would therefore be completely exempt.
As for people who claim they never watch terrestrial, or listen to BBC radio, or browse the BBC news website or anything else the licence funds - bullshit.
No it wouldn't, because the TV licence doesn't cover devices solely operated by batteries (which I presume would cover phones if the charger disabled TV service). But I wouldn't worry, because Sky (satellite) would charge you 300 to watch their stations through it and inflict as much advertising on to you as UK broadcast standards permit.
But what is.NET? Show me where.NET (in the CLR / C# sense) finishes and SQL Server.NET begins. Is it in ADO.NET or what? If you don't know, what chance does some clueless manager?
All they hear at the seminar is that ".NET has a portable runtime just like Java and offers an end to end solution". And then the brain disengages without detecting the ambiguity. How many ask for clarification - the runtime might be portable but has it been ported and what about the rest, is that portable and ported too? Of course any company switching over might learn their mistake when it is far too late to correct. This premise also presumes Java needs replacing when it rarely does for any reason, especially not to another runtime language.
Even the client side stuff in.NET like the Forms demonstrates there is no portability there. Look at the hoops that the Mono folks have to do to support it - linking to Wine no less. In other words, to implement Forms (and PInvoke) you have to emulate an entire Win32 API!
And there is the constant threat of harrassment hanging over the project if ever it gets too good for Microsoft's liking.
This is why I think mono is wasting its time really pursuing.NET libs. Support for semi-core libs such as Forms might be okay but draw a line in the sand. Offer a viable alternative in GTK# and other open technologies which give people no reason to use windows.forms. Better yet, implement plugins for Eclipse which make it easy to visually design and build apps for GTK# that run on any platform.
After all, DevStudio used to be a premier development platform but these days it is looking distinctly ropey especially for the fortune it costs. With a bit of coaxing Eclipse could do everything DevStudio offers but with the added benefit that the code it produces truly runs anywhere
You're not locked in because there are multiple JVMs and multiple implentations spanning multiple architectures and devices from multiple vendors. You are not compelled to use Sun hardware, nor Sun software if you want to use something else. Many of the core technologies are open specifications with open source implementations.
Thus you have a lot more choice. You could be using Java on Mac OS X, Tomcat and PostgreSQL to power your website, or you could be using IBM mainframes with WebLogic and an Oracle backend.
With.NET your choices are made for you - Microsoft. Microsoft software on Microsoft operating systems on Microsoft supported platforms. Mono might be suitable for toy apps (not that Kaffe is much better) but it is never going to implement all of the proprietary things that.NET is comprised of.
This finally puts Java the language onto the same level as c#. While most of the syntax changes amount to sugar (the compiled code being the same), it is still welcom to see a proper enum at last. And things like generics should make it considerably less tedious to walk through collections (a bane of Java development).
Another change that caught my eye was a skinnable theme for JFC called Synth. I wonder if this will help Java capture some of the kewl market for media players etc.
I also see the beta is being made available for 64-bit Linux.
As a platform, Java is still miles ahead of c#. But I sometimes wonder if the message is lost amongst all the specifications and implementations of specifications. The.NET strategy has gotten some ill-deserved 'buzz' from managers who've heard the spiel without quite understanding the implications if they go that route (i.e. lock-in). Someone in Suns marketing department should produce a massive wallchart detailing everything Java can do, every major solution for it and arrows showing how they all join together and then mail it out to every CEO / CTO in the country.
I don't believe Eclipse would be in any way as good if Sun had gotten their hands on it. It would probably be the bloated JFC, non native, non standard, unintuitive slug that Netbeans became. Everyone would moan about the awful performance and appearance and it would have been delivered stillborn.
Fortunately, SWT looks like a native app and Eclipse looks like it could be written in any language. This does a lot to dispel the myth that Java is slow - JFC is slow but Java isn't. In fact Eclipse & SWT may well be the saviour for Java, especially when it becomes apparant that Java can produce native looking and fast tools and be cross-platform at the same time. What was the reason for using.NET again?
Of course, it would be useful to have Sun on board, but I suspect if they had a controlling position, they'd immediately steer the project straight for the nearest rocks.
The thing is, that done right a picture phone with web browsing can work pretty well. I have a Sony Ericsson T610 and it's probably the best phone I've owned - it's simple to use, texting is very good, it takes pictures, it does great WAP and it's positively tiny for the functionality it contains.
But perhaps perspectives are skewed for most/. users, given that the US phone market is still a dog's dinner compared to the EU or elsewhere. Functionality such as texting or roaming is old hat and de rigeur for the likes of Vodafone so new features are not to the detriment of the old ones.
Well yes and no. PkZip seems to have licenced RSA BSAFE for their mechanism which make it less likely you'll see versions of InfoZip that support it (at least fully) because it is more complex and possibly proprietary. So there goes portability. And let's hope it doesn't favour some appallingly slow public key based encryption.
Whereas WinZip have chosen an off-the-shelf algorithm, a GPL implementation of that algorithm and published the full specs to how they've extended the zip format.
So a user who knows not about such matters might conclude that PKZip performs like a slug, costs more thanks to licencing or is non-standard while WinZip is none of those things.
When I refer to the RFM crowd I am referring to the knee jerks who pick up on any suggestion that Linux be made easier (i.e. that comparable tasks to Windows / Mac take a comparable amount of time), by ranting about unskilled users or suggesting you RTFM.
Can't connect to your ISP? RTFM. Can't get 3d working on your graphics card? RTFM. Can't change screen resolution? RTFM. Can't create a shortcut on your desktop? RTFM.
And so on. It's transparently obvious to some that such issues are the fault of the dist, not the user, but that doesn't stop the snorting superiority and outrage. Suggest it on Linux Today that [insert dist here] has a fault and watch the reaction.
The thing is Mac OS X is an OS grandma can use but you can also open a shell and completely ignore Aqua if you want.
So the problem with Linux is not technical. If OS X (a BSD derivative) can have a user friendly frontend then so could Linux. That means proper attention to detail in the UI, user friendliness, hiding advanced options, extensive context sensitive help, wizards and config dialogs, plug and play on the desktop, 3D graphics support (out of the box), and consumer device support. Etc.
Some dists get a lot of this right already (e.g. Fedora has a very nice UI without detracting from the underlying OS) so we're not far from that situation. Hopefully initiatives such as this one from OSDL will help put focus on the work that still needs to be done. It doesn't mean dumbing down Lindows style - a well designed and tolerant UI benefits everyone.
Another major millstone for Linux is the RTFM crowd. At the moment they're acting like so much dead weight to adoption of Linux. Hopefully they'll get a clue and realise the more users the better. And that is not going to happen while a vocal minority are openly hostile to letting mere mortals use their beloved OS.
I'm not paranoid and I don't believe every company is out to get me.
I'm just pointing out how totally wrong you are when you state there are no privacy issues. And these are just examples I thought up on the spot. Read cryptogram or comp.risks in a few years and you'll no doubt see real world examples.
If you had stepped back and thought about it even for a second you would have realized that for yourself before sticking your foot in your mouth.
It has more to do with the relatively low employment costs and the tax breaks than anything else. Countries such as Denmark, Holland & Belgium all have a lot of fluent English speakers and are probably 'closer' to Europe than Ireland is.
Screw unix services. I'd love to see user mode linux appear for Windows.
Aside from the kewl factor, it would be incredibly useful for me since I could run Linux at near native speeds side by side with Windows on my laptop - download a Debian image configured to run X / vnc and away I'd go.
I imagine it would even make a fantastic 1-click to run demo to distribute on CDs and so forth.
And why do you suppose an RFID number is sacrosanct and untraceable? Speedpass shares that number with its retailers. Speedpass could go out of business and sell its list, or change its T&C at any time. Besides which what if Albertsons becomes a speedpass retailer or Harrahs etc. ? Then they can do exactly what I proposed because Speedpass let's them.
As for the RFID being too weak to read, that really depends on the 'reader' that emits the radio signal that the RFID responds to. Emit a stronger signal and you'll pick up RFIDs further away - as you walk through a door way for example, or just by standing at the checkout counter, or as you walk past a store front or even 100 feet away. Short of leaving the keychain / watch / whatever containing your speedpass at home (and thus rendering it useless) you can be detected simply by being in the general vicinity of a reader.
Even if Speedpass had a cast iron privacy policy (which it doesn't). What's to stop someone simply reading your RFID when you make a purchase with your credit card? It's easy - set up a reader by the cash register (which some stores intend on doing anyway) and wait for you to hand over your credit card or store card and bang - your speedpass and details have now been associated. A few database collations later and your name, address and speedpass number are being passed around to who knows who.
It's not far fetched - the technology is already there. Give the market a few more years and the dots will all be joined. So yes there are privacy issues.
Yes there is. Does this watch only reveal its ID when you consent or could any sensor you happen to pass pick up your ID? Is that ID tied to your personal details in some way? Are those personal details likely to be sold? Are you likely to hang onto a $50 watch for a considerable period of time?
If the answer to any of these is 'yes'. Then there are most certainly privacy issues. If some lousy fast food chain can read your details you can bet anyone else could too, without your permission. How long before it's collated? Perhaps you walked past an adult store once and now they're sending you their rubberwear catalogue. Maybe Albertsons will set up an unobtrusive looking van at the entrance of a Safeway which listens to see who is buying groceries there. Perhaps you'll get unsolicited calls from holiday firms who detected you standing in front of a picture of Hawaii in the mall. Perhaps casinos will begin adjusting the minimum table bets based on who's standing around and their self control. You get the idea.
It would be different if you had to push and hold a button to enable the chip, thereby restricting its use. In that scenario the privacy implications are the same as for a credit card. But if it's 'always on' I would suggest it has enormous privacy implications.
Who says it has to be forced? But it should be an option. Not everyone has the luxury of multiple desktops (Win32 users for one, but probably many Linux users too), so an MDI option is important.
As for the taskbar, I'm sure you can make it work in a number of ways. Personally I like an individual tab for evry window. Irrespective of the way you use it, it is still a poor substitute for an app which has UI shortcomings.
Not in the case. If you had used GIMP or any other graphics tool you would realise that MDI is essential. The problem with GIMP 1.2 (and only somewhat lessened by tabs in 1.3/2.x) is that you're forever playing 'hunt' the window because all the GIMP tool bars (all umpteen of them) are forever getting lost on your desktop and the task bar doesn't help much because it is so densely packed.
The 'workaround' is start it up on its own desktop, but this is essentially just allowing you to do what MDI would have let you do in the first place.
Another solution would be to make all the windows leap to the front in unison a la Mac, which would make some sense but then this would probably bring its own issues.
Don't forget the VideoLAN player. I downloaded it the other day for Win32 and was most impressed. The UI is kind of arcane, but it is able to play DVDs (with decss built in) and all sorts of audio and media content straight out of the box.
I didn't say it was impossible, but it is difficult and inefficient. Using objects defined in one language from another, means shadowing objects with counterparts in the other language, keeping large lookup tables, and dealing with horrible issues such as lifetimes, temporary pointers, refcounting and so forth. It's very inefficient, fragile and complicated. Even something as simple as setting or getting text on a widget is inefficient since you must construct a temporary QString in order to do it.
That would explain why QT has a fraction of the bindings compared to GTK. Because it's easy to do in GTK and devilishly hard to do in QT.
Sorry but this is dumb. If you want to use C++ with GTK it is as simple as writing a class with methods that call the C counterparts. If you prefer you can use one of the ready-made C++ bindings that already exist for GTK such as the official gtkmm. It's not that GTK 'hates' C++, rather that it makes no sense to implement the base API in high level C++ and shut out every other language in the process.
In other words if you like things abstract you can have it, if you don't or require low level access you can have that too. I'm comfortable with either way. On Win32 for example I'll use WTL / ATL (I despise MFC) for the general moving windows around and layout, but will often drop to Win32 APIs when using wrapper classes is pointless.
So I suggest there that some people have valid reason for shunning the 'obvious technical merits' of QT. I don't disagree it has its own strengths, but requiring someone to program in C++ to use it isn't one of them.
Especially since terrorists have the awful habit of blowing up the plane they are on en route to US or hijacking domestic flights when they get there, or when they leave the country.
How does fingerprinting help in any of these circumstances?
If iTunes sells songs in some crappy DRM format which restricts my ownership of that song, then I simply don't see what the incentive is to use it. Once that file is in my possession I should be able to do anything I like with it subject to copyright law. If I want to cut it to disk, or play it on my MP3 CD player, or on my Linux box I should be able to. If I backup those files and find them in a box in 20 years hence I should still be able to play them, no matter what hardware is around by then. If I want to transfer ownership of the songs to others (as I can with books and CDs) then this too should be possible.
The fact is that iPod is promoting a lock-in, highly restrictive music format - not as restrictive as it could be but it's still the thin end of the wedge. If it solds songs in industry standard MP3 or an open format such as OGG as it could so easily do (with watermarking or some other form of tagging to prevent illicit trading), then I would feel more inclined to give it a go. But then it doesn't.
This isn't just an Apple thing. Microsoft will no doubt promote their equally crappy WMA format when they get around to launching their own service. Then the question will be which of the two is the most evil.
As for iTunes not supporting other countries - that is just another reason to ignore it. I'm sure they'll get around to supporting the UK and other markets, charging the usual 1 = $1 markup, but I suspect they have quite a few legal issues to sort out before that happens.
I've handled the existing iPod and frankly I can't see what the fuss is about. They're heavy for their size and the shiny smooth design seems like an excellent mechanism for making them slip from your hands and smash to pieces.
A smaller iPod does look a lot cuter except for the price. Firewire is a pretty nice feature to be sure, but I don't see much else going for it. The iTunes site doesn't even work outside of the US and doesn't sell songs in MP3 (or OGG). This pretty much negates any point of buying an iPod for me.
Besides which, Creative and Rio both have comparable offerings, so I'm not sure what people find so amazing about the iPod. It was actually bizarre to be in the Chicago Apple store (as I was last week) and see the amount of shit that is available to accesorize the thing.
You're not replacing widgets, just the engine which renders their appearance. Even if GTK were using the default QT theme it would still contain the same 'feel' as GTK even if it looked different.
A unified theme engine is a good thing. The hardest thing is abstracting out the differences in how both GTK and QT go about rendering their buttons. Perhaps it would be as well to produce some abstract widget-neutral interfaces for this kind of thing.
Slashdot Mirror
As for people who claim they never watch terrestrial, or listen to BBC radio, or browse the BBC news website or anything else the licence funds - bullshit.
No it wouldn't, because the TV licence doesn't cover devices solely operated by batteries (which I presume would cover phones if the charger disabled TV service). But I wouldn't worry, because Sky (satellite) would charge you 300 to watch their stations through it and inflict as much advertising on to you as UK broadcast standards permit.
All they hear at the seminar is that ".NET has a portable runtime just like Java and offers an end to end solution". And then the brain disengages without detecting the ambiguity. How many ask for clarification - the runtime might be portable but has it been ported and what about the rest, is that portable and ported too? Of course any company switching over might learn their mistake when it is far too late to correct. This premise also presumes Java needs replacing when it rarely does for any reason, especially not to another runtime language.
Even the client side stuff in .NET like the Forms demonstrates there is no portability there. Look at the hoops that the Mono folks have to do to support it - linking to Wine no less. In other words, to implement Forms (and PInvoke) you have to emulate an entire Win32 API!
And there is the constant threat of harrassment hanging over the project if ever it gets too good for Microsoft's liking.
This is why I think mono is wasting its time really pursuing .NET libs. Support for semi-core libs such as Forms might be okay but draw a line in the sand. Offer a viable alternative in GTK# and other open technologies which give people no reason to use windows.forms. Better yet, implement plugins for Eclipse which make it easy to visually design and build apps for GTK# that run on any platform.
After all, DevStudio used to be a premier development platform but these days it is looking distinctly ropey especially for the fortune it costs. With a bit of coaxing Eclipse could do everything DevStudio offers but with the added benefit that the code it produces truly runs anywhere
Thus you have a lot more choice. You could be using Java on Mac OS X, Tomcat and PostgreSQL to power your website, or you could be using IBM mainframes with WebLogic and an Oracle backend.
With
Another change that caught my eye was a skinnable theme for JFC called Synth. I wonder if this will help Java capture some of the kewl market for media players etc.
I also see the beta is being made available for 64-bit Linux.
As a platform, Java is still miles ahead of c#. But I sometimes wonder if the message is lost amongst all the specifications and implementations of specifications. The
Fortunately, SWT looks like a native app and Eclipse looks like it could be written in any language. This does a lot to dispel the myth that Java is slow - JFC is slow but Java isn't. In fact Eclipse & SWT may well be the saviour for Java, especially when it becomes apparant that Java can produce native looking and fast tools and be cross-platform at the same time. What was the reason for using
Of course, it would be useful to have Sun on board, but I suspect if they had a controlling position, they'd immediately steer the project straight for the nearest rocks.
But perhaps perspectives are skewed for most
Whereas WinZip have chosen an off-the-shelf algorithm, a GPL implementation of that algorithm and published the full specs to how they've extended the zip format.
So a user who knows not about such matters might conclude that PKZip performs like a slug, costs more thanks to licencing or is non-standard while WinZip is none of those things.
Can't connect to your ISP? RTFM. Can't get 3d working on your graphics card? RTFM. Can't change screen resolution? RTFM. Can't create a shortcut on your desktop? RTFM.
And so on. It's transparently obvious to some that such issues are the fault of the dist, not the user, but that doesn't stop the snorting superiority and outrage. Suggest it on Linux Today that [insert dist here] has a fault and watch the reaction.
So the problem with Linux is not technical. If OS X (a BSD derivative) can have a user friendly frontend then so could Linux. That means proper attention to detail in the UI, user friendliness, hiding advanced options, extensive context sensitive help, wizards and config dialogs, plug and play on the desktop, 3D graphics support (out of the box), and consumer device support. Etc.
Some dists get a lot of this right already (e.g. Fedora has a very nice UI without detracting from the underlying OS) so we're not far from that situation. Hopefully initiatives such as this one from OSDL will help put focus on the work that still needs to be done. It doesn't mean dumbing down Lindows style - a well designed and tolerant UI benefits everyone.
Another major millstone for Linux is the RTFM crowd. At the moment they're acting like so much dead weight to adoption of Linux. Hopefully they'll get a clue and realise the more users the better. And that is not going to happen while a vocal minority are openly hostile to letting mere mortals use their beloved OS.
Sad-Fuckers-R-Us
I'm just pointing out how totally wrong you are when you state there are no privacy issues. And these are just examples I thought up on the spot. Read cryptogram or comp.risks in a few years and you'll no doubt see real world examples.
If you had stepped back and thought about it even for a second you would have realized that for yourself before sticking your foot in your mouth.
It has more to do with the relatively low employment costs and the tax breaks than anything else. Countries such as Denmark, Holland & Belgium all have a lot of fluent English speakers and are probably 'closer' to Europe than Ireland is.
Aside from the kewl factor, it would be incredibly useful for me since I could run Linux at near native speeds side by side with Windows on my laptop - download a Debian image configured to run X / vnc and away I'd go.
I imagine it would even make a fantastic 1-click to run demo to distribute on CDs and so forth.
As for the RFID being too weak to read, that really depends on the 'reader' that emits the radio signal that the RFID responds to. Emit a stronger signal and you'll pick up RFIDs further away - as you walk through a door way for example, or just by standing at the checkout counter, or as you walk past a store front or even 100 feet away. Short of leaving the keychain / watch / whatever containing your speedpass at home (and thus rendering it useless) you can be detected simply by being in the general vicinity of a reader.
Even if Speedpass had a cast iron privacy policy (which it doesn't). What's to stop someone simply reading your RFID when you make a purchase with your credit card? It's easy - set up a reader by the cash register (which some stores intend on doing anyway) and wait for you to hand over your credit card or store card and bang - your speedpass and details have now been associated. A few database collations later and your name, address and speedpass number are being passed around to who knows who.
It's not far fetched - the technology is already there. Give the market a few more years and the dots will all be joined. So yes there are privacy issues.
Yes there is. Does this watch only reveal its ID when you consent or could any sensor you happen to pass pick up your ID? Is that ID tied to your personal details in some way? Are those personal details likely to be sold? Are you likely to hang onto a $50 watch for a considerable period of time?
If the answer to any of these is 'yes'. Then there are most certainly privacy issues. If some lousy fast food chain can read your details you can bet anyone else could too, without your permission. How long before it's collated? Perhaps you walked past an adult store once and now they're sending you their rubberwear catalogue. Maybe Albertsons will set up an unobtrusive looking van at the entrance of a Safeway which listens to see who is buying groceries there. Perhaps you'll get unsolicited calls from holiday firms who detected you standing in front of a picture of Hawaii in the mall. Perhaps casinos will begin adjusting the minimum table bets based on who's standing around and their self control. You get the idea.
It would be different if you had to push and hold a button to enable the chip, thereby restricting its use. In that scenario the privacy implications are the same as for a credit card. But if it's 'always on' I would suggest it has enormous privacy implications.
As for the taskbar, I'm sure you can make it work in a number of ways. Personally I like an individual tab for evry window. Irrespective of the way you use it, it is still a poor substitute for an app which has UI shortcomings.
The 'workaround' is start it up on its own desktop, but this is essentially just allowing you to do what MDI would have let you do in the first place.
Another solution would be to make all the windows leap to the front in unison a la Mac, which would make some sense but then this would probably bring its own issues.
Don't forget the VideoLAN player. I downloaded it the other day for Win32 and was most impressed. The UI is kind of arcane, but it is able to play DVDs (with decss built in) and all sorts of audio and media content straight out of the box.
That would explain why QT has a fraction of the bindings compared to GTK. Because it's easy to do in GTK and devilishly hard to do in QT.
In other words if you like things abstract you can have it, if you don't or require low level access you can have that too. I'm comfortable with either way. On Win32 for example I'll use WTL / ATL (I despise MFC) for the general moving windows around and layout, but will often drop to Win32 APIs when using wrapper classes is pointless.
So I suggest there that some people have valid reason for shunning the 'obvious technical merits' of QT. I don't disagree it has its own strengths, but requiring someone to program in C++ to use it isn't one of them.
How does fingerprinting help in any of these circumstances?
If iTunes sells songs in some crappy DRM format which restricts my ownership of that song, then I simply don't see what the incentive is to use it. Once that file is in my possession I should be able to do anything I like with it subject to copyright law. If I want to cut it to disk, or play it on my MP3 CD player, or on my Linux box I should be able to. If I backup those files and find them in a box in 20 years hence I should still be able to play them, no matter what hardware is around by then. If I want to transfer ownership of the songs to others (as I can with books and CDs) then this too should be possible.
The fact is that iPod is promoting a lock-in, highly restrictive music format - not as restrictive as it could be but it's still the thin end of the wedge. If it solds songs in industry standard MP3 or an open format such as OGG as it could so easily do (with watermarking or some other form of tagging to prevent illicit trading), then I would feel more inclined to give it a go. But then it doesn't.
This isn't just an Apple thing. Microsoft will no doubt promote their equally crappy WMA format when they get around to launching their own service. Then the question will be which of the two is the most evil.
As for iTunes not supporting other countries - that is just another reason to ignore it. I'm sure they'll get around to supporting the UK and other markets, charging the usual 1 = $1 markup, but I suspect they have quite a few legal issues to sort out before that happens.
A smaller iPod does look a lot cuter except for the price. Firewire is a pretty nice feature to be sure, but I don't see much else going for it. The iTunes site doesn't even work outside of the US and doesn't sell songs in MP3 (or OGG). This pretty much negates any point of buying an iPod for me.
Besides which, Creative and Rio both have comparable offerings, so I'm not sure what people find so amazing about the iPod. It was actually bizarre to be in the Chicago Apple store (as I was last week) and see the amount of shit that is available to accesorize the thing.
A unified theme engine is a good thing. The hardest thing is abstracting out the differences in how both GTK and QT go about rendering their buttons. Perhaps it would be as well to produce some abstract widget-neutral interfaces for this kind of thing.