Do you really want to use an office suite that's a homonym of "FUBAR" ?
Oh wait, never mind. Most of the reasons I need to leave the comfort of the shell and emacs and pick up an office suite are FUBARed already. Sounds like a perfect fit to me...
And here are 187 OpenOffice bugs and feature requests that received at least 25 votes.
Oh, cool. That must have taken a bit of time to put a link to each one of those bugs in your commen.... dear sweet-n-sour sassafras!!! are my eyes deceiving me or is that just one fu*cking huge URL in your comment there?
You know, slashdot does have support for the A-HREF tag...
I remember seeing Dell computers preinstalled with Ubuntu were often times even more expensive than their Windows counterparts.
I managed to get one of my employers to buy me one of the pre-installed Ubuntu laptops from Dell. It was a pretty good laptop, and the specs were actually roughly what I needed, but I was acutely aware of how much choice there was on the Windows-laptop storefront at Dell and how little choice there was on the tiny little outpost of a page for Dell Ubuntu systems.
The OS did come with fully paid-up licenses for playing DVDs and (I believe) mp3s, with perhaps other license fees as well. So Dell's per-laptop cost for installing Ubuntu was definitely non-zero, even before you figured in labor and time/effort to create the custom images.
It's tough. I'd like to support companies who offer hardware without Windows, but there's not only lack of a financial incentive, sometimes it's much cheaper to get the laptop with Windows and just replace the OS.
But perhaps it's best to have a nuanced view on the matter. As long as the hardware has enough kernel support that everything from the webcam to the touchpad to hibernation just works under the latest build of Fedora or Ubuntu, the burden of Windows is reduced to a minor issue in the big scheme of buying at new laptop. While I'd like to have the manufacturers offer us the hardware unbundled, it's just not a choice today. And hardware support is much more important to me than whether I bought an unneeded $25 OEM copy of Windows.
The Joule technology requires no "feedstock," no corn, no wood, no garbage, no algae. Aside from hungry, gene-altered micro-organisms, it requires only carbon dioxide and sunshine to manufacture crude. And water: whether fresh, brackish or salt.
How can anyone with a high school chemistry education take this bullshit seriously?
Water is H2O. Add to that mixture CO2 and a bunch of energy (in this case, sunshine), and I believe that you could make pretty much any hydrocarbon you desire (with some amount of leftover O2).
So based on my understanding of organic chemistry, it sounds possible. Whether it's plausible is another question entirely...
First off, remember that when WebM burst onto the scene, Google made it pretty clear that they didn't want to monkey-around with improving the VP8 codec. Sure, maybe it could be improved, but they basically said that they just wanted to leave it as-is and have people start using the darn thing. The benefit of having it in use out in the wild outweighed any delays.
So, by submitting VP8 to the IETF as an RFC, they're not (necessarily) revisiting the question of making improvements or tweaks to VP8, but they are making progress on standardizing the codec.
Second, after the stunts with OOXML in ISO, if they actually want everyone to use VP8 in WebM for all of their web video needs, they might just want to avoid those jokers. I don't know too much about the w3c, OASIS, ECMA, or any of those other standards bodies, but I'm not sure if those would be appropriate places to go to standardize a codec, anyhow.
Third, IPR (Intellectual/Imaginary Property Rights). The IETF has an RFC (of course it's an RFC!) about IPR, including a description of who needs to disclose information about possible IPR and when.
Here's an excerpt:
6.1. Who Must Make an IPR Disclosure?
6.1.1. A Contributor's IPR in his or her Contribution
Any Contributor who reasonably and personally knows of IPR meeting
the conditions of Section 6.6 which the Contributor believes Covers
or may ultimately Cover his or her Contribution, or which the
Contributor reasonably and personally knows his or her employer or
sponsor may assert against Implementing Technologies based on such
Contribution, must make a disclosure in accordance with this Section
6.
This requirement specifically includes Contributions that are made by
any means including electronic or spoken comments, unless the latter
are rejected from consideration before a disclosure could reasonably
be submitted. An IPR discloser is requested to withdraw a previous
disclosure if a revised Contribution negates the previous IPR
disclosure, or to amend a previous disclosure if a revised
Contribution substantially alters the previous disclosure.
Contributors must disclose IPR meeting the description in this
section; there are no exceptions to this rule.
6.1.2. An IETF Participant's IPR in Contributions by Others
Any individual participating in an IETF discussion who reasonably and
personally knows of IPR meeting the conditions of Section 6.6 which
the individual believes Covers or may ultimately Cover a Contribution
made by another person, or which such IETF participant reasonably and
personally knows his or her employer or sponsor may assert against
Implementing Technologies based on such Contribution, must make a
disclosure in accordance with this Section 6.
I don't think that Google necessarily expects to see the MPEG-LA boys show up en force to describe all of the patents they have that they think read on VP8. Yes, it's too bad. But I don't think it's too unreasonable to believe that anyone who gets involved in a discussion about this RFC will need to disclose any IPR they know about. If Google or someone else can get employees from some of the primary codec-patent-owning companies to be at all involved in the discussion, this could force them to tip their hand regarding patents (or risk legal problems later for failing to disclose them at this time).
Overall, not much work for Google with the possibility of some big payoffs later. Very slick.
If you think an Android phone is any more FOSS than an iPhone, I have a FOSS bridge I would like to sell you.
Hey, I'm not happy with some of the stuff Google has done with Android, including their proprietary apps on top of it, but if you're trying to argue that iOS and Android are anywhere close in terms of FOSSyness, I've gotta call bull on that.
Android uses the iPhone browser core.
Sure. And AFAIK the stock browser on Android is open, while the iOS browser is closed. Even if the stock Android is closed, that's a draw.
iOS is BSD-based and built with LLVM.
Windows used to use a BSD-based TCP stack, but that didn't mean that any regular person could use it separately or build on the code.
Android's OS is actually open, even if it's developed in private. You and I can get copies and build it. Easily. On machines we already own. Today.
Android wins this one, hands down.
Android phones are riddled with crapware and carrier restrictions
There are no carrier restrictions on the iPhone? And what if I want to remove some of the apps from the iPhone -- aren't there some I can't remove?
Sure, there might be extra crap added-in by carriers on Android phones, but that doesn't mean that the underlying OS is any less free.
And unlike iOS, I believe that regular users can get GPLed applications from the Android Market.
and in the US are often proprietary CDMA with no SIM.
That's why I dumped Verizon and picked up T-mobile.
And it's funny that you'd mention CDMA providers, because the iPhone is coming to Verizon (CDMA) in the near future.
It is a wash.
Whaaa? I mean look, I could deal with it if you were a straight-up Mac fanboi, but if you really think that the iOS platform is open, you are seriously deluding yourself.
At least with iOS it is sold directly to you by a vendor whose only interest is blowing your mind so much that you come back for another iPhone in 2 years.
If Apple really wanted to blow my mind, why don't they include porn in the App store?
(On a side note, how in the world are they going to allow a Playboy app in there, since Jobs made that comment about keeping the app store clean of all pornography?)
At least with iOS you get updates delivered automatically the day they are out of testing.
Hey, delivering updates automatically and quickly is a good bonus. But unfortunately it has zero correlation with a given application being FOSS.
Out of all of the mobile OSes available on the market today, Android is clearly the most FOSSy. Apple's iOS may be 2nd, but unlike things like the Replicant project for Android, I just don't see any way of taking iOS and making it much more FOSSy. It's just not going to happen...
I've got to be honest here. I really liked the idea of MeeGo, but I'm almost beginning to feel embarrassed to even talk about the OS given the fact that the project was announced 9 months ago, was based on two existing OSes that were usable, and still doesn't have any handset hardware shipping with it. Heck -- as far as I know the functionality of MeeGo on the n900 isn't even up to par with Maemo.
Anyhow, getting back to the point of this post, I wonder how the Oracle/Google kerfuffule is affecting Meego. If MeeGo were mature enough to ship on hardware, I could see a persuasive argument being made against Android. The uncertainty around the Java base of Android might convince some hardware manufacturers to try building their next toys on top of MeeGo. The problem is that I don't get the perception that we're going to see anything shipping w/MeeGo soon, and by the time that comes to pass, Google and Oracle will likely have worked out some kind of deal in mediation -- Groklaw has already noted that the two parties have agreed to hire an external mediator to sort out their issues.
Of course, there's something even worse than MeeGo missing this opportunity to grab a little marketshare: Android losing marketshare. Looking out at the landscape right now, Android is the only thing standing between you and a completely proprietary OS running on your mobile device. Think about it.
Sure, I was okay running whatever dinky OS they wanted to put on my old cell phone. It didn't even take pictures, and I only made calls and sent txts with the thing. But the problem is that our cell phones are now being used to store tons of private data. I'd wager that, Megabyte for Megabyte, for a large number of people there is more personal data stored on their cell phone than on their laptop. Just as I run FOSS on my laptop, I'd really like to run FOSS on my mobile devices.
So while I don't expect Nokia to go bail-out Google, it's worth considering the fact that Google is holding its own here. Hopefully Nokia and Intel can crank on MeeGo and bring another powerful FOSS mobile OS to the party. We're all waiting with baited breath.
If I had to set up a multi-desktop deployment, I'd be very keen to look into running a GNU/Linux system and then adding on top of that any "must-have" Windows-only applications (either using WINE or virtualization).
I'm not really sure I see the benefits of the particular hybrid approach of layering KDE on top of Windows. If you're a user, you'll still get some of the issues w/Windows, even for mundane tasks that work equally well on Windows and on a Unix-y system. And unlike running a few virtualized apps if and when necessary, you're still dragging around the Windows OS for every user, even those people that don't need any Windows-based applications.
I'd be curious to see how many large companies/organizations have gone with WINE/virtualization for the few apps that are only available for Windows, and what kinds of problems they've faced.
They offer "unlimited data" just like restaurants offer "free refills". Restaurants expect you to refill a certain number of times given the size of your cup and the duration of your visit. If you start funneling your beverage into a keg you've brought in with you, someone will probably ask you to leave.
Both cases seem fair to me.
The problem here is that you can't program your body the same way you can program a smartphone.
So "free refills" at a restaurant should probably include all of the stuff that you can drink in a reasonable amount of time (say, maybe until they close for the night or whatever). If you hand the cup to a friend, that's off-limits.
But unlike the human body that usually might consume a pint of liquid with a meal...and might be able to consume up to a gallon (only 8x as much), a smartphone with a fast connection could easily be used to watch streaming video. And while the average smartphone out there might only be sending/receiving a few MB daily, anyone who watches streaming video will be consuming a few MB every minute, if not every few seconds.
The vast disparity between the average user and the heavy user is incredibly more noticeable with the phones; the restaurant can much more easily average out the excesses of the heavy users than the mobile ISPs.
What I don't understand is why the FCC or FTC doesn't just hit them over the head and say "Look, just tell the truth in your advertising and we'll leave you alone!" Have them only advertise "unlimited" connections if they're truly all-you-can-consume packages. If they're capped at 10G/month, then bloody well say that in the advertising. So simple, so easy.
Read the spec, or just stab myself with a fork? Tough decisions...
Okay, maybe the specs are better written these days, but the last time I tried to read through specs for DirectX and OpenGL I felt like I was in some kind of special Hell...
While I'm totally supportive of reasonable scientific expeditions down to see the wreckage, I am rather amused that the ship will eventually just dissolve away. At some point it all just turns to dust and gets recycled by the planet into new things. Even the physical object that we want to be most immutable -- the 1kg reference mass in France -- is beyond our ability to keep pristine. But there's no shame in that, for we are but mere mortals, muddling our way through the mysteries of the universe on our little, watery planet.
In the end, it seems like a fitting and dignified end to the ship and to all of the souls who went down on her.
...all of these electric cars will probably be pulling as much or more power than even a big bank of grow lights.
I'm sure that people have already started figuring out ways to shape their energy usage to make it look like they have a new electric car at home, instead of... a shed full of lush, green plants!
I don't know about hats, but it sure sounds like you're trolling!
What's stopping Google from using code in the MeeGo base?
MeeGo uses a (somewhat) stock kernel, I believe. Android puts in all kinds of special sauce not in mainline like wake-locks.
Drivers written for Android aren't necessarily going to just work in MeeGo, unless you add all that additional stuff (cruft?) to the kernel, etc...
Like most popular distros, MeeGo uses the standard GNU userland; Android uses their own, non-GPL userland.
we'll probably see a lot of cross contamination between Android and MeeGo kernel code.
Sure, anything that's from upstream.
(I suspect that since Android's source is completely open, there would be no...
Android, like MeeGo is largely open. But there are certain things that are not released under a FOSS license (e.g. some drivers, particularly power-related and graphics-related drivers).
On Android, I believe that all of Google's core applications are completely closed-source. What's more, it's non-trivial to set up the phone to sync with non-Google servers.
Nokia would steal Google's UI code and Dalvik
I don't think that Android's UI is particularly better or worse than MeeGo's.
And Dalvik? That's like asking the MeeGo folks to go stick their hand in a beehive filled with thousands of tiny little Larry Ellisons with stingers. Surely, you must be joking!
Google would steal their best threading, i/o, and whatever other code is probably superior in MeeGo that isn't probably going to wind up in the base kernel trunk
Part of the whole point with MeeGo is to try to get as much stuff pushed up into upstream projects as is possible. If there's some good threading or i/o improvements to be made to the kernel, it seems reasonable that the MeeGo kernel devs will work hard to get it into mainline. From my perspective, Android has an "after the fact" attitude towards kernel development, whereas MeeGo has more of a "let's cooperate with upstream" attitude.
I don't know if ARM is working directly on the Linux kernel/Android or not
Sure. One of the projects they sponsor is Linaro. Linaro is a projects tasked with making it easier to deploy Linux-based systems on top of ARM: http://www.linaro.org/
They call me the Silk Badd Boyy of IP, sued daily for Patent Infringement, but I'm like "hey, Man, what's up with the Satin Perstringement?"
In 59 states, all chomping at the bit, there are lawyers by the dozens, want to catch me in their mit, they say this musical maestro committed a sin of Patent Infringement, My Danzón beats are so off the hook, I'm called "The Latin Unhingement."
can you think of a rhyme for "patent infringement"?
Oh hai, it's me right here, in your base, improper spellah, droppin' fools like db tables, vampire tap your cables (like a bella), 'code 3 or 4 lines, you might get sued for Patent Infringement, Software Patents make no sense, just like Combatant Inpingement.
Slashdot Mirror
Would the government be able to triangulate position of the send/receive devices?
If not, or at least not easily, we could try to get some tech into the right hands over there...
we could call ours 'THE Office' or somethin' just to mess with them. ;-)"
"Dude...you got Office?" "No man...better. I got THE Office!
Sure, but then some smartass would include an animated "Clippy"-type character that looked like Dwight Schrute.
"It looks like you're writing a children's book. Would you like some tips from the author of Struwwelpeter?".
Do you really want to use an office suite that's a homonym of "FUBAR" ?
Oh wait, never mind. Most of the reasons I need to leave the comfort of the shell and emacs and pick up an office suite are FUBARed already. Sounds like a perfect fit to me...
And here are 187 OpenOffice bugs and feature requests that received at least 25 votes.
Oh, cool. That must have taken a bit of time to put a link to each one of those bugs in your commen.... dear sweet-n-sour sassafras!!! are my eyes deceiving me or is that just one fu*cking huge URL in your comment there?
You know, slashdot does have support for the A-HREF tag...
(battle/2 == knowing)
I remember seeing Dell computers preinstalled with Ubuntu were often times even more expensive than their Windows counterparts.
I managed to get one of my employers to buy me one of the pre-installed Ubuntu laptops from Dell. It was a pretty good laptop, and the specs were actually roughly what I needed, but I was acutely aware of how much choice there was on the Windows-laptop storefront at Dell and how little choice there was on the tiny little outpost of a page for Dell Ubuntu systems.
The OS did come with fully paid-up licenses for playing DVDs and (I believe) mp3s, with perhaps other license fees as well. So Dell's per-laptop cost for installing Ubuntu was definitely non-zero, even before you figured in labor and time/effort to create the custom images.
It's tough. I'd like to support companies who offer hardware without Windows, but there's not only lack of a financial incentive, sometimes it's much cheaper to get the laptop with Windows and just replace the OS.
But perhaps it's best to have a nuanced view on the matter. As long as the hardware has enough kernel support that everything from the webcam to the touchpad to hibernation just works under the latest build of Fedora or Ubuntu, the burden of Windows is reduced to a minor issue in the big scheme of buying at new laptop. While I'd like to have the manufacturers offer us the hardware unbundled, it's just not a choice today. And hardware support is much more important to me than whether I bought an unneeded $25 OEM copy of Windows.
The Joule technology requires no "feedstock," no corn, no wood, no garbage, no algae. Aside from hungry, gene-altered micro-organisms, it requires only carbon dioxide and sunshine to manufacture crude. And water: whether fresh, brackish or salt.
How can anyone with a high school chemistry education take this bullshit seriously?
Water is H2O. Add to that mixture CO2 and a bunch of energy (in this case, sunshine), and I believe that you could make pretty much any hydrocarbon you desire (with some amount of leftover O2).
So based on my understanding of organic chemistry, it sounds possible. Whether it's plausible is another question entirely...
Creating an RFC was a very smart move for Google.
First off, remember that when WebM burst onto the scene, Google made it pretty clear that they didn't want to monkey-around with improving the VP8 codec. Sure, maybe it could be improved, but they basically said that they just wanted to leave it as-is and have people start using the darn thing. The benefit of having it in use out in the wild outweighed any delays.
So, by submitting VP8 to the IETF as an RFC, they're not (necessarily) revisiting the question of making improvements or tweaks to VP8, but they are making progress on standardizing the codec.
Second, after the stunts with OOXML in ISO, if they actually want everyone to use VP8 in WebM for all of their web video needs, they might just want to avoid those jokers. I don't know too much about the w3c, OASIS, ECMA, or any of those other standards bodies, but I'm not sure if those would be appropriate places to go to standardize a codec, anyhow.
Third, IPR (Intellectual/Imaginary Property Rights). The IETF has an RFC (of course it's an RFC!) about IPR, including a description of who needs to disclose information about possible IPR and when.
Here's an excerpt:
6.1. Who Must Make an IPR Disclosure?
6.1.1. A Contributor's IPR in his or her Contribution
Any Contributor who reasonably and personally knows of IPR meeting
the conditions of Section 6.6 which the Contributor believes Covers
or may ultimately Cover his or her Contribution, or which the
Contributor reasonably and personally knows his or her employer or
sponsor may assert against Implementing Technologies based on such
Contribution, must make a disclosure in accordance with this Section
6.
This requirement specifically includes Contributions that are made by
any means including electronic or spoken comments, unless the latter
are rejected from consideration before a disclosure could reasonably
be submitted. An IPR discloser is requested to withdraw a previous
disclosure if a revised Contribution negates the previous IPR
disclosure, or to amend a previous disclosure if a revised
Contribution substantially alters the previous disclosure.
Contributors must disclose IPR meeting the description in this
section; there are no exceptions to this rule.
6.1.2. An IETF Participant's IPR in Contributions by Others
Any individual participating in an IETF discussion who reasonably and
personally knows of IPR meeting the conditions of Section 6.6 which
the individual believes Covers or may ultimately Cover a Contribution
made by another person, or which such IETF participant reasonably and
personally knows his or her employer or sponsor may assert against
Implementing Technologies based on such Contribution, must make a
disclosure in accordance with this Section 6.
I don't think that Google necessarily expects to see the MPEG-LA boys show up en force to describe all of the patents they have that they think read on VP8. Yes, it's too bad. But I don't think it's too unreasonable to believe that anyone who gets involved in a discussion about this RFC will need to disclose any IPR they know about. If Google or someone else can get employees from some of the primary codec-patent-owning companies to be at all involved in the discussion, this could force them to tip their hand regarding patents (or risk legal problems later for failing to disclose them at this time).
Overall, not much work for Google with the possibility of some big payoffs later. Very slick.
If you think an Android phone is any more FOSS than an iPhone, I have a FOSS bridge I would like to sell you.
Hey, I'm not happy with some of the stuff Google has done with Android, including their proprietary apps on top of it, but if you're trying to argue that iOS and Android are anywhere close in terms of FOSSyness, I've gotta call bull on that.
Android uses the iPhone browser core.
Sure. And AFAIK the stock browser on Android is open, while the iOS browser is closed. Even if the stock Android is closed, that's a draw.
iOS is BSD-based and built with LLVM.
Windows used to use a BSD-based TCP stack, but that didn't mean that any regular person could use it separately or build on the code.
Android's OS is actually open, even if it's developed in private. You and I can get copies and build it. Easily. On machines we already own. Today.
Android wins this one, hands down.
Android phones are riddled with crapware and carrier restrictions
There are no carrier restrictions on the iPhone? And what if I want to remove some of the apps from the iPhone -- aren't there some I can't remove?
Sure, there might be extra crap added-in by carriers on Android phones, but that doesn't mean that the underlying OS is any less free.
And unlike iOS, I believe that regular users can get GPLed applications from the Android Market.
and in the US are often proprietary CDMA with no SIM.
That's why I dumped Verizon and picked up T-mobile.
And it's funny that you'd mention CDMA providers, because the iPhone is coming to Verizon (CDMA) in the near future.
It is a wash.
Whaaa? I mean look, I could deal with it if you were a straight-up Mac fanboi, but if you really think that the iOS platform is open, you are seriously deluding yourself.
At least with iOS it is sold directly to you by a vendor whose only interest is blowing your mind so much that you come back for another iPhone in 2 years.
If Apple really wanted to blow my mind, why don't they include porn in the App store?
(On a side note, how in the world are they going to allow a Playboy app in there, since Jobs made that comment about keeping the app store clean of all pornography?)
At least with iOS you get updates delivered automatically the day they are out of testing.
Hey, delivering updates automatically and quickly is a good bonus. But unfortunately it has zero correlation with a given application being FOSS.
Out of all of the mobile OSes available on the market today, Android is clearly the most FOSSy. Apple's iOS may be 2nd, but unlike things like the Replicant project for Android, I just don't see any way of taking iOS and making it much more FOSSy. It's just not going to happen...
If someone with a supercomputer is trying to break your encryption, I would think you have bigger problems to worry about.
Yeah, like the energy bill for that supercomputer. Don't even get me started on the carbon credits you'll need to purchase...
what does P stand for?
Portman.
Oh wait, sorry, I was answering the comment above yours...
I've got to be honest here. I really liked the idea of MeeGo, but I'm almost beginning to feel embarrassed to even talk about the OS given the fact that the project was announced 9 months ago, was based on two existing OSes that were usable, and still doesn't have any handset hardware shipping with it. Heck -- as far as I know the functionality of MeeGo on the n900 isn't even up to par with Maemo.
Anyhow, getting back to the point of this post, I wonder how the Oracle/Google kerfuffule is affecting Meego. If MeeGo were mature enough to ship on hardware, I could see a persuasive argument being made against Android. The uncertainty around the Java base of Android might convince some hardware manufacturers to try building their next toys on top of MeeGo. The problem is that I don't get the perception that we're going to see anything shipping w/MeeGo soon, and by the time that comes to pass, Google and Oracle will likely have worked out some kind of deal in mediation -- Groklaw has already noted that the two parties have agreed to hire an external mediator to sort out their issues.
Of course, there's something even worse than MeeGo missing this opportunity to grab a little marketshare: Android losing marketshare. Looking out at the landscape right now, Android is the only thing standing between you and a completely proprietary OS running on your mobile device. Think about it.
Sure, I was okay running whatever dinky OS they wanted to put on my old cell phone. It didn't even take pictures, and I only made calls and sent txts with the thing. But the problem is that our cell phones are now being used to store tons of private data. I'd wager that, Megabyte for Megabyte, for a large number of people there is more personal data stored on their cell phone than on their laptop. Just as I run FOSS on my laptop, I'd really like to run FOSS on my mobile devices.
So while I don't expect Nokia to go bail-out Google, it's worth considering the fact that Google is holding its own here. Hopefully Nokia and Intel can crank on MeeGo and bring another powerful FOSS mobile OS to the party. We're all waiting with baited breath.
As far as I know, Google develops Android internally, then spits out versions every so often, kind of like laying an egg.
What part does the OHA play?
...before virtualisation was as usable as now,..
Key words: Before now.
If I had to set up a multi-desktop deployment, I'd be very keen to look into running a GNU/Linux system and then adding on top of that any "must-have" Windows-only applications (either using WINE or virtualization).
I'm not really sure I see the benefits of the particular hybrid approach of layering KDE on top of Windows. If you're a user, you'll still get some of the issues w/Windows, even for mundane tasks that work equally well on Windows and on a Unix-y system. And unlike running a few virtualized apps if and when necessary, you're still dragging around the Windows OS for every user, even those people that don't need any Windows-based applications.
I'd be curious to see how many large companies/organizations have gone with WINE/virtualization for the few apps that are only available for Windows, and what kinds of problems they've faced.
They offer "unlimited data" just like restaurants offer "free refills". Restaurants expect you to refill a certain number of times given the size of your cup and the duration of your visit. If you start funneling your beverage into a keg you've brought in with you, someone will probably ask you to leave.
Both cases seem fair to me.
The problem here is that you can't program your body the same way you can program a smartphone.
So "free refills" at a restaurant should probably include all of the stuff that you can drink in a reasonable amount of time (say, maybe until they close for the night or whatever). If you hand the cup to a friend, that's off-limits.
But unlike the human body that usually might consume a pint of liquid with a meal...and might be able to consume up to a gallon (only 8x as much), a smartphone with a fast connection could easily be used to watch streaming video. And while the average smartphone out there might only be sending/receiving a few MB daily, anyone who watches streaming video will be consuming a few MB every minute, if not every few seconds.
The vast disparity between the average user and the heavy user is incredibly more noticeable with the phones; the restaurant can much more easily average out the excesses of the heavy users than the mobile ISPs.
What I don't understand is why the FCC or FTC doesn't just hit them over the head and say "Look, just tell the truth in your advertising and we'll leave you alone!" Have them only advertise "unlimited" connections if they're truly all-you-can-consume packages. If they're capped at 10G/month, then bloody well say that in the advertising. So simple, so easy.
Enjoy your homework reading the OpenGL spec.
Read the spec, or just stab myself with a fork? Tough decisions...
Okay, maybe the specs are better written these days, but the last time I tried to read through specs for DirectX and OpenGL I felt like I was in some kind of special Hell...
While I'm totally supportive of reasonable scientific expeditions down to see the wreckage, I am rather amused that the ship will eventually just dissolve away. At some point it all just turns to dust and gets recycled by the planet into new things. Even the physical object that we want to be most immutable -- the 1kg reference mass in France -- is beyond our ability to keep pristine. But there's no shame in that, for we are but mere mortals, muddling our way through the mysteries of the universe on our little, watery planet.
In the end, it seems like a fitting and dignified end to the ship and to all of the souls who went down on her.
"at" now?
When i wrote that I had been up for far too long.... which, come to think of it, is also the case at this very minute....hmmm...
I wonder if it has something to do with my profession (namely, trying to pretend that we can stay up as long as the computers we shepherd...)
(Also, now.com is apparently the site of some Hong Kong TV company)
at Burger King in favor of a WOPR rather than a Big Mac...
I am so hungry right now! And I also have a strange urge to go find an acoustic coupler for my phone and invite Ally Sheedy to my place...
But seriously, a burger would be awesome @now. Really.
Where's the (-1, naïve) button??
Patented (duh!)
...all of these electric cars will probably be pulling as much or more power than even a big bank of grow lights.
I'm sure that people have already started figuring out ways to shape their energy usage to make it look like they have a new electric car at home, instead of... a shed full of lush, green plants!
in Eureka.
He's pretty young. Who cares if he's not real. Heroes are larger than life, anyhow, right?
*puts on anti-Nokia troll hat*
I don't know about hats, but it sure sounds like you're trolling!
What's stopping Google from using code in the MeeGo base?
MeeGo uses a (somewhat) stock kernel, I believe. Android puts in all kinds of special sauce not in mainline like wake-locks.
Drivers written for Android aren't necessarily going to just work in MeeGo, unless you add all that additional stuff (cruft?) to the kernel, etc...
Like most popular distros, MeeGo uses the standard GNU userland; Android uses their own, non-GPL userland.
we'll probably see a lot of cross contamination between Android and MeeGo kernel code.
Sure, anything that's from upstream.
(I suspect that since Android's source is completely open, there would be no...
Android, like MeeGo is largely open. But there are certain things that are not released under a FOSS license (e.g. some drivers, particularly power-related and graphics-related drivers).
On Android, I believe that all of Google's core applications are completely closed-source. What's more, it's non-trivial to set up the phone to sync with non-Google servers.
Nokia would steal Google's UI code and Dalvik
I don't think that Android's UI is particularly better or worse than MeeGo's.
And Dalvik? That's like asking the MeeGo folks to go stick their hand in a beehive filled with thousands of tiny little Larry Ellisons with stingers. Surely, you must be joking!
Google would steal their best threading, i/o, and whatever other code is probably superior in MeeGo that isn't probably going to wind up in the base kernel trunk
Part of the whole point with MeeGo is to try to get as much stuff pushed up into upstream projects as is possible. If there's some good threading or i/o improvements to be made to the kernel, it seems reasonable that the MeeGo kernel devs will work hard to get it into mainline. From my perspective, Android has an "after the fact" attitude towards kernel development, whereas MeeGo has more of a "let's cooperate with upstream" attitude.
I don't know if ARM is working directly on the Linux kernel/Android or not
Sure. One of the projects they sponsor is Linaro. Linaro is a projects tasked with making it easier to deploy Linux-based systems on top of ARM: http://www.linaro.org/
And what am I, chopped liver?
Two more:
They call me the Silk Badd Boyy of IP, sued daily for Patent Infringement,
but I'm like "hey, Man, what's up with the Satin Perstringement?"
In 59 states, all chomping at the bit,
there are lawyers by the dozens, want to catch me in their mit,
they say this musical maestro committed a sin of Patent Infringement,
My Danzón beats are so off the hook, I'm called "The Latin Unhingement."
can you think of a rhyme for "patent infringement"?
Oh hai, it's me right here, in your base, improper spellah,
droppin'
fools like db tables, vampire tap your cables (like a bella),
'code 3 or 4 lines, you might get sued for Patent Infringement,
Software Patents make no sense, just like Combatant Inpingement.