Doesn't quite mesh with the statistics I've heard. I've always heard that in a recession, the person with the lower education (assuming they're still qualified) is likely to get hired, because they're the one who is less likely to jump ship as soon as a better job comes around. It's the basic problem of being overqualified during a recession that a lot of people are facing.
There once was a man from Japan Whose limericks just wouldn't scan. When asked why this was, he said "It's because, I always try to fit as many syllables onto the last line as I possibly can."
Basically, the simple answer is that in the Google Maps app, you have to tell the app when you've reached a turn. It doesn't detect it. (So you have to hit "Next" a bunch of times through your route) The TomTom app will detect when you're close to a turn, tell you (out loud, even) and advance to the next step in the route.
I think the turn-by-turn technology (basically the ability to detect when you've completed a turn) is patented, so the Google Maps app does all it's really allowed to do without infringing patents (hence the need for you to tell it when you've completed a turn.) This also would explain why no turn-by-turn apps are allowed in the app store.
They *had* tested with only 30kW of power, because they were waiting for their superconductor to ship. Once it was delivered (in late June, according to TFA) they were able to get to higher outputs. I closed the tab and now it's slashdotted, so I forget the amount, but it was above 100kW and they're waiting until the 14th to do their full-scale test, expected to reach 200kW.
Google is good at... gathering and indexing information.
Google is also good at hiring whoever they want with experience in any field they want experience in. Look what they did to Microsoft. They could just hire every open source developer they can get their hands on and say "Work on the same thing, and we'll pay you truckloads of money."
Right now all GNU/Linux distributions can easily read and write to fat, fat32 and NTFS.
I would hardly call NTFS writing "easy". As of right now you need captive-ntfs, which uses WINE to load the ntfs.sys driver from an existing windows install (if you have the right version that it expects), and even then, it writes at about 200KB/s. That's about as slow as a DSL connection. NTFS write() support just made it into the upstream kernel (2.6.15), but you can't create or remove files, only write to them. (If you attempt to, you'll get filesystem corruption.)
It's a braindead waste of time. I don't see how I can put it more politely. It actively hurts the Free Software ecosystem.
Except that it makes it easier for developers to create managable, maintainable software under Linux using a free, standards compliant (yes, it was submitted to ECMA and C# is a standard) open source, and familiar language.
As of right now, pretty much all the mono projects exist happily within the linux ecosystem and occasionally see windows ports. And yes, they're ports. In order to run mono apps in windows, you have to either recompile for.NET IL code, or actually install a mono runtime in windows. And even then, a lot of the code in the mono apps in linux use bindings to existing linux (C/C++) libraries such as GTK, gstreamer, etc... so porting those to windows would also involve porting the corresponding libraries.
I've used and programmed mono apps for a while, and I never once thought of it as a way to bridge a compatibility gap between linux and windows. It's just a kick-ass development environment for Linux. I'd want mono for Fedora simply so I can have Beagle, at the very least. If you'd stop trolling and actually look at it that way, you'd find that it is by no means a "brain-dead waste of time."
I was under the impression that they work the same way as the pen-in-hand method, in that the pad itself is powered, and it simply senses where the mouse is. That's why the pad feels so awkward when the mouse is angled 45 degrees... You have to move the mouse *up* on the tablet for the pointer on the screen to move up, not just move the mouse forward.
They're microsoft. They could simply compile a ground-up implementation of the win32 libraries for linux. Why would they use a reverse engineered, poorly implemented version of their own code?
But with that logic, they would've probably done the same for Office for the Mac. I guess the dev's like the Mac development environment enough to port their drawing code to Cocoa. (But they sure as hell would *hate* porting it to GTK.)
It's not in sid yet, if that's what you mean (although RC1 is...)
Developers don't care about making debian packages for their software. The Debian guys do that for them. (So long as their code is GPL.) And that's the way it should be.
One thing's for sure though, ubuntu will probably have it first.:-P
Please stop spreading FUD you stupid troll.
1) Yes they are compatible. The packages conflict sometimes, but it's nothing you can't get around by manually selecting packages.
a) And they're *certainly* "binary compatible". It's not like they run on a different kernel or something, stupid ass.
2) If you want to still have sid, but with minor fixes to make it more ubuntu compatible, you put the universe branch in your sources.list. It's pretty much the entire unstable branch, but on ubuntu mirrors, with additional ubuntu QA put into them. It works perfectly for me.
I'm typing this from a laptop running ubuntu, dist-upgraded from sid. It works perfectly.
And pray tell, what is the percentage of the population of servers that actually *need* any of those features? How many admins want to swap in a different scheduler for their kernels? How many servers are (or how many admins actually want) >32 processors anyway? Isn't it much easier to cluster your servers together? I mean, it's easy... And isn't it much more likely that solaris' user base is entirely due to the average sysadmin thinking "Hmm, everyone else seems to use solaris, and it's been around for a long time! I'll use that!" Wouldn't most admins prefer usability over all those esoteric features?
And for that matter, won't "hot swappable cpus" require sun hardware? Last time I checked, you couldn't pull the CPU out of a multi processor xserve.
And keep in mind, this is the company that told us hardware should be free, and people should only pay for software. (not really on topic, but I just thought that was an exceptionally dumb statement.)
Slashdot Mirror
Doesn't quite mesh with the statistics I've heard. I've always heard that in a recession, the person with the lower education (assuming they're still qualified) is likely to get hired, because they're the one who is less likely to jump ship as soon as a better job comes around. It's the basic problem of being overqualified during a recession that a lot of people are facing.
I'll take my fixie internet any day. You probably don't have the taste to appreciate such things, though.
Grant hunting is a year-round sport, baby.
"On the eighth day god created turok" without vowels. Not that hard to remember.
There's not nearly as much solar wind that far out, I would think.
Hit shift+c to compose in a new window. Then you don't have to wait that OMG ETERNITY of 1-2 seconds to return to your inbox.
There once was a man from Japan
Whose limericks just wouldn't scan.
When asked why this was,
he said "It's because,
I always try to fit as many syllables onto the last line as I possibly can."
Also DHCP. Which is rather important in most networks, I'd think, no?
Basically, the simple answer is that in the Google Maps app, you have to tell the app when you've reached a turn. It doesn't detect it. (So you have to hit "Next" a bunch of times through your route) The TomTom app will detect when you're close to a turn, tell you (out loud, even) and advance to the next step in the route.
I think the turn-by-turn technology (basically the ability to detect when you've completed a turn) is patented, so the Google Maps app does all it's really allowed to do without infringing patents (hence the need for you to tell it when you've completed a turn.) This also would explain why no turn-by-turn apps are allowed in the app store.
Holy crap! It's APK, the legend himself! He Who Shall Not Be Mentioned! http://episteme.arstechnica.com/eve/forums/a/tpc/f/12009443/m/1810993821?r=2310969821 You're a legend in the Ars forums, man. Hats off to your amazing ability to troll. You don't see many who master the craft like you do anymore.
Wait, nevermind. The site came up, and you're right, the second stage adds an extra 170kW and is expected to commence testing on July 14.
They *had* tested with only 30kW of power, because they were waiting for their superconductor to ship. Once it was delivered (in late June, according to TFA) they were able to get to higher outputs. I closed the tab and now it's slashdotted, so I forget the amount, but it was above 100kW and they're waiting until the 14th to do their full-scale test, expected to reach 200kW.
Also, .NET 4.0 is supposed to ship with the Dynamic Language Runtime (DLR): http://en.wikipedia.org/wiki/Dynamic_Language_Runtime
Thanks, slashdot, for swallowing my comment.
Meant to say: Both of these issues were fixed a long time ago. Get with it.
Both of thesei
Or you can just use a print stylesheet like you're supposed to. You know, that thing that browsers support by default?
Google is also good at hiring whoever they want with experience in any field they want experience in. Look what they did to Microsoft. They could just hire every open source developer they can get their hands on and say "Work on the same thing, and we'll pay you truckloads of money."
Right now all GNU/Linux distributions can easily read and write to fat, fat32 and NTFS.
I would hardly call NTFS writing "easy". As of right now you need captive-ntfs, which uses WINE to load the ntfs.sys driver from an existing windows install (if you have the right version that it expects), and even then, it writes at about 200KB/s. That's about as slow as a DSL connection. NTFS write() support just made it into the upstream kernel (2.6.15), but you can't create or remove files, only write to them. (If you attempt to, you'll get filesystem corruption.)
It's a braindead waste of time. I don't see how I can put it more politely. It actively hurts the Free Software ecosystem.
.NET IL code, or actually install a mono runtime in windows. And even then, a lot of the code in the mono apps in linux use bindings to existing linux (C/C++) libraries such as GTK, gstreamer, etc... so porting those to windows would also involve porting the corresponding libraries.
Except that it makes it easier for developers to create managable, maintainable software under Linux using a free, standards compliant (yes, it was submitted to ECMA and C# is a standard) open source, and familiar language.
As of right now, pretty much all the mono projects exist happily within the linux ecosystem and occasionally see windows ports. And yes, they're ports. In order to run mono apps in windows, you have to either recompile for
I've used and programmed mono apps for a while, and I never once thought of it as a way to bridge a compatibility gap between linux and windows. It's just a kick-ass development environment for Linux. I'd want mono for Fedora simply so I can have Beagle, at the very least. If you'd stop trolling and actually look at it that way, you'd find that it is by no means a "brain-dead waste of time."
I was under the impression that they work the same way as the pen-in-hand method, in that the pad itself is powered, and it simply senses where the mouse is. That's why the pad feels so awkward when the mouse is angled 45 degrees... You have to move the mouse *up* on the tablet for the pointer on the screen to move up, not just move the mouse forward.
They're microsoft. They could simply compile a ground-up implementation of the win32 libraries for linux. Why would they use a reverse engineered, poorly implemented version of their own code? But with that logic, they would've probably done the same for Office for the Mac. I guess the dev's like the Mac development environment enough to port their drawing code to Cocoa. (But they sure as hell would *hate* porting it to GTK.)
It's not in sid yet, if that's what you mean (although RC1 is...)
:-P
Developers don't care about making debian packages for their software. The Debian guys do that for them. (So long as their code is GPL.) And that's the way it should be.
One thing's for sure though, ubuntu will probably have it first.
Fuck, I selected html formatted instead of plain text. Point stands, albiet hard to read.
Please stop spreading FUD you stupid troll. 1) Yes they are compatible. The packages conflict sometimes, but it's nothing you can't get around by manually selecting packages. a) And they're *certainly* "binary compatible". It's not like they run on a different kernel or something, stupid ass. 2) If you want to still have sid, but with minor fixes to make it more ubuntu compatible, you put the universe branch in your sources.list. It's pretty much the entire unstable branch, but on ubuntu mirrors, with additional ubuntu QA put into them. It works perfectly for me. I'm typing this from a laptop running ubuntu, dist-upgraded from sid. It works perfectly.
And pray tell, what is the percentage of the population of servers that actually *need* any of those features? How many admins want to swap in a different scheduler for their kernels? How many servers are (or how many admins actually want) >32 processors anyway? Isn't it much easier to cluster your servers together? I mean, it's easy... And isn't it much more likely that solaris' user base is entirely due to the average sysadmin thinking "Hmm, everyone else seems to use solaris, and it's been around for a long time! I'll use that!" Wouldn't most admins prefer usability over all those esoteric features?
And for that matter, won't "hot swappable cpus" require sun hardware? Last time I checked, you couldn't pull the CPU out of a multi processor xserve.
And keep in mind, this is the company that told us hardware should be free, and people should only pay for software. (not really on topic, but I just thought that was an exceptionally dumb statement.)