Mono + wine, of late, were starting to be able to run some of the.net apps associated with games. For instance, if you ask it very nicely, mono + wine can run the Need For Speed World launcher/patcher (and was able to do so before.net + wine could).
There are lots of bugs left to fix in mono before it can handle more.net 3-era apps, let alone WPF apps, which would be Really Hard.
I read "The Daemon" and "Freedom" ( http://thedaemon.com/ ) in one night each. They give me the same sinking feeling of doom I had back when I first realized how insecure computers were. And they're where I first heard about isobutanol being used as a biofuel.
Really? Bruce Byfield is upset that Ubuntu switched its/etc/init.d handler to upstart?
That's an awfully picky thing to complain about, especially since other distros did, too.
Switching to the Unity shell is a bit edgy, but hey, it's been a while since there's actually been competition in desktops, we could use some.
Most people long ago picked Gnome or KDE, and those projects have to some extent been coasting.
Perhaps Unity will light a fire under Gnome like Chrome did for Firefox...
If California's Metrolink trains took 45 minutes instead of 90 minutes to get from LA to Irvine, I could actually use them.
So about friggin' time. Let's get this show on the road before gasoline hits $6/gallon.
Boy, I wish I could mod this up. Iron is definitely a scam. (I was in the chromium irc channel when its developer came on the scene, and he openly admitted he was just playing on people's fears. It seems his goal is to make money with google ads on the download page.) Disclaimer: I used to work on Chromium at Google, now I'm just a happy user.
Installations of Google Chrome that are obtained from promotional campaigns send information regarding the effectiveness of the campaigns to Google. Installations of Google Chrome obtained by directly visiting www.google.com/chrome do not send this information. This information is required for compliance with contractual obligations where Google must accurately measure the effectiveness of promotional campaigns. This includes a non-unique promotional tag that contains information about how Chrome was obtained (e.g. from an online advertisement, bundled with another software product, etc.) and the week that Chrome was installed. The tag looks similar to: 1T4ADBR_enUS236US239. This non-unique tag is periodically sent to Google and is also appended to the URL on Google searches that originate from the Omnibox (the tag appears as a parameter beginning with "rlz="). We use this information to help us measure the searches driven by a particular promotion. Installations of Google Chrome obtained via promotional campaigns also send a token when you first launch Chrome and when you first use the Omnibox. The same token will be sent if Chrome is later reinstalled, and is only sent at first launch and at first use of the Omnibox after reinstallation. Rather than store the token on the computer, it is generated when necessary by using built-in system information that is scrambled in an irreversible manner. Again, instances of Google Chrome obtained by directly visiting www.google.com/chrome and not via promotional campaigns do not use these tags or tokens."
So I think it's already gone, at least if you're downloading from google.com/chrome, and the Wikipedia article needs updating.
Disclaimer: I'm a chromium developer, and I used to work for Google, but I don't speak for the Chromium team or Google.
Yes, I remember well when the guy who does Iron showed up on the chromium mailing list. When I suggested he submit patches to fix the privacy problems, he came right out and said he didn't want to because he was planning on making money by scaring users into using Iron. (I think I saw the chat logs posted not long ago to/.) He seemed quite cynical about it; I wouldn't trust the guy myself.
"Don't let the LSB people fool you. There is no single, common, standard Linux ABI set to target when developing a commercial app"
Not true. If you build your app against X86 LSB 3.2, it'll run on any X86 Linux distro that supports LSB 3.2. You have to package it twice, once as rpm and once as deb, to reach everybody, but that's not so hard. And if there are libraries missing from the LSB, you have to link them statically, or hope that they have the same package name and ABI on all distros.
That said, commercial ISVs really don't have much incentive to support fringe distros. 99% of the linux desktop market is covered by ubuntu/debian, red hat/fedora, suse/opensuse, and maybe mandriva, so that's what ISVs will test against. If you're running something else, and the ISV's app doesn't work, chances are the ISV won't even get enough problem reports to know that it needs fixing. But since that kind of problem doesn't affect 99% of users, that's not so bad. And there's always the chance that the distro can fix the problem (after all, if it works on the four major distros, it's probably not the app's fault).
The LA Times, for some reason, came out against the proposal today. This fired me up, so I spent some time putting together notes on the subject at http://kegel.com/energy/television/ in hopes that it'd help me write a killer letter-to-the-editor explaining why they're wrong:-)
"Energy Star requires power consumption of less than 1 watt in standby to qualify."
Well, yes. But Energy Star by itself voluntary. The proposed regulations *require* Energy Star compliance:
"If the commission adopts the new rules, beginning in 2011, California retailers would be able to sell only TVs that meet the guidelines of the voluntary federal Energy Star program."
For the record: Google Earth and Google Sketchup have true native ports to Linux.
Google Picasa used Wine for its port; it's the only one that uses any kind of compatibility layer, I think.
(Disclaimer: although I work on Chrome, and worked on Picasa, I'm speaking for myself, not the company.)
Hey Max, I am totally a fan of your DIB engine work. It's been wonderful watching you attack this difficult job. I do hope you're able to see it through to the end! - Dan
The original poster is essentially expressing frustration
at the slow pace of Wine development. The direct antidote
to that general problem is more wine developers.
For the specific case of the DIB engine, we need to
free up quite a bit of e.g. Huw and/or Alexandre's time.
I'm sure they'd love to work on this, but they have
to eat. If you don't want to become a wine developer,
perhaps you could raise the needed cash to get a DIB
engine integrated. Jeremy White had Huw give it a
shot with some support from Google. He had to stop
after something like 10^5 $ because it wasn't an
obvious win yet, and the end wasn't in sight.
Once Max has demonstrated code that has the needed
performance, it'll be time to try to clean it up to
Alexandre's standards. Since Max doesn't want to do
that, and no developer is stepping up to the plate to
try it (maybe somebody could convince Jesse?),
it might be worth it for somebody to
fund another push. If you aren't a developer, you
could help by raising oh, say $50K to let Huw and
Alexandre get started on this once it's time.
It's not clear that would be enough to finish, but it
would let them focus on it for a while.
I'm one of the Picasa for Linux developers
(though I work on Chrome for Linux now), and
I was also the release manager for Wine 1.0.
Picasa for Linux does not use Winelib, it uses Wine.
We run the exact Windows binary without recompilation.
There is very little reason to use winelib when
porting a Windows app to x86 Linux.
Earth for Linux is a native app, it does not use Wine at all.
And while we're on the subject of Wine: two big reasons
Wine is still important are:
Wine (unlike vmware or virtualbox) does not require a
copy of Windows, which, last I checked, still costs money.
(Yeah, I know, it comes with lots of PCs, but if you
check MS's support agreements, you have to buy a
second copy of Windows if you want enterprise support.)
Wine doesn't require you to fire up a whole virtual
machine; it just translates API calls. This is often
quite a bit faster.
Now, on to Max's DIB engine: he's doing a great job, and
I have faith that the Wine maintainer is also doing a
great job at keeping Wine healthy. The bar for inclusion
of a patch in Wine is very high, and that's a good thing.
Many developers get frustrated by Alexandre's relative
lack of feedback, but imagine yourself in Alexandre's shoes;
he would get overwhelmed if he held everybody's hands.
Max's DIB engine is a great prototype. If he can get it
to the point where it passes all tests, doesn't cause
performance regressions, and does yield large performance
improvements for important apps, the core Wine devs
*will* take it, clean it up (which might involve rewriting
large parts of it), and integrate it -- once they get
time/funding to do so. They want a good DIB engine very
badly, but not badly enough to do a rush job or
neglect their paying customers. Writing and/or integrating
a DIB engine is a huge job. We owe Max and those who
went before him (Jesse, Huw,...) a lot for getting things
this far. There's lots left to do, and I hope Max keeps plugging
away, and that others join in.
I am really looking forward to seeing what happens.
I was in a study about nine years ago in which I was given norplant implants plus weekly testosterone injections.
(I think I was in Group 4 of this study or a very similar one.)
The injections were annoying but not painful; I self-injected in large leg muscles (front or back).
It was effective (my sperm count went to zero) and reversible (we conceived without difficulty a year or so later).
HOWEVER, the effect on my mood was not pleasant. To me, it seemed like the world was a less reasonable place. To others, it seemed like I was more irritable and less fun to be around. I don't recommend the experience!
There are daily builds you could try. They're pre-alpha, though, so don't expect too much yet. Or you could build it from source, it's not too hard. See http://chromium.org/
I have a better idea: let's take the $10 million
and hire programmers to fix the open bugs in Wine.
There are about 5000 open bugs, and the stock
estimate for cost of fixing the average bug is
$2000, so it works out nicely.
How 'bout we all write letters to our congressmen
to propose the idea?
Slashdot Mirror
Mono + wine, of late, were starting to be able to run some of the .net apps associated with games. For instance, if you ask it very nicely, mono + wine can run the Need For Speed World launcher/patcher (and was able to do so before .net + wine could).
There are lots of bugs left to fix in mono before it can handle more .net 3-era apps, let alone WPF apps, which would be Really Hard.
Also, fwiw, it was posted on an fbi site in 2004 as well: http://waybackmachine.org/20041115000000*/http://foia.fbi.gov/hottel_guy/hottel_guy_part01.pdf
I read "The Daemon" and "Freedom" ( http://thedaemon.com/ ) in one night each. They give me the same sinking feeling of doom I had back when I first realized how insecure computers were. And they're where I first heard about isobutanol being used as a biofuel.
Ejecta from a collision with early Earth seems the most likely explanation. Pretty cool, but not proof of life coming from elsewhere.
Really? Bruce Byfield is upset that Ubuntu switched its /etc/init.d handler to upstart?
That's an awfully picky thing to complain about, especially since other distros did, too.
Switching to the Unity shell is a bit edgy, but hey, it's been a while since there's actually been competition in desktops, we could use some.
Most people long ago picked Gnome or KDE, and those projects have to some extent been coasting.
Perhaps Unity will light a fire under Gnome like Chrome did for Firefox...
If California's Metrolink trains took 45 minutes instead of 90 minutes to get from LA to Irvine, I could actually use them. So about friggin' time. Let's get this show on the road before gasoline hits $6/gallon.
The Chrome team watches pretty carefully for performance regressions, see http://build.chromium.org/buildbot/perf/dashboard/overview.html The buildbot will go red if there's a big one, and people watch the graphs for creeping regressions.
Boy, I wish I could mod this up. Iron is definitely a scam. (I was in the chromium irc channel when its developer came on the scene, and he openly admitted he was just playing on people's fears. It seems his goal is to make money with google ads on the download page.) Disclaimer: I used to work on Chromium at Google, now I'm just a happy user.
Check out
http://www.google.com/intl/en/landing/chrome/google-chrome-privacy-whitepaper.pdf
It says
"Promotional tags and tokens
Installations of Google Chrome that are obtained from promotional campaigns send information regarding
the effectiveness of the campaigns to Google. Installations of Google Chrome obtained by directly visiting
www.google.com/chrome do not send this information.
This information is required for compliance with contractual obligations where Google must accurately
measure the effectiveness of promotional campaigns.
This includes a non-unique promotional tag that contains information about how Chrome was obtained
(e.g. from an online advertisement, bundled with another software product, etc.) and the week that
Chrome was installed. The tag looks similar to: 1T4ADBR_enUS236US239. This non-unique tag is
periodically sent to Google and is also appended to the URL on Google searches that originate from the
Omnibox (the tag appears as a parameter beginning with "rlz="). We use this information to help us
measure the searches driven by a particular promotion.
Installations of Google Chrome obtained via promotional campaigns also send a token when you first
launch Chrome and when you first use the Omnibox. The same token will be sent if Chrome is later
reinstalled, and is only sent at first launch and at first use of the Omnibox after reinstallation. Rather than
store the token on the computer, it is generated when necessary by using built-in system information that
is scrambled in an irreversible manner.
Again, instances of Google Chrome obtained by directly visiting www.google.com/chrome and not via
promotional campaigns do not use these tags or tokens."
So I think it's already gone, at least if you're downloading from google.com/chrome, and the Wikipedia article needs updating.
Disclaimer: I'm a chromium developer, and I used to work for Google, but I don't speak for the Chromium team or Google.
Yes, I remember well when the guy who does Iron showed /.)
up on the chromium mailing list. When I suggested
he submit patches to fix the privacy problems, he came
right out and said he didn't want to because he was
planning on making money by scaring users into using Iron.
(I think I saw the chat logs posted not long ago to
He seemed quite cynical about it; I wouldn't trust the guy myself.
If you know of a privacy problem with Chrome's latest
dev channel release, please post a bug to the chromium bug tracker.
See http://code.google.com/p/chromium/issues/list?can=2&q=privacy
for open bugs that mention privacy.
Disclaimer: I'm a chromium dev (and I used to work at google).
"Don't let the LSB people fool you. There is no single, common, standard Linux ABI set to target when developing a commercial app"
Not true. If you build your app against X86 LSB 3.2, it'll run on any X86 Linux distro that supports LSB 3.2.
You have to package it twice, once as rpm and once as deb, to reach everybody, but that's not so hard.
And if there are libraries missing from the LSB, you have to link them statically, or hope that
they have the same package name and ABI on all distros.
That said, commercial ISVs really don't have much incentive to support fringe distros. 99% of the linux desktop market is covered by ubuntu/debian, red hat/fedora, suse/opensuse, and maybe mandriva, so that's what ISVs will test against. If you're running something else, and the ISV's app doesn't work, chances are the ISV won't even get enough problem reports to know that it needs fixing. But since that kind of problem doesn't affect 99% of users, that's not so bad. And there's always the chance that the distro can fix the problem (after all, if it works on the four major distros, it's probably not the app's fault).
The LA Times, for some reason, came out against :-)
the proposal today. This fired me up, so
I spent some time putting together notes on the
subject at
http://kegel.com/energy/television/
in hopes that it'd help me write a killer
letter-to-the-editor explaining why they're wrong
"Energy Star requires power consumption of less than 1 watt in standby to qualify."
Well, yes. But Energy Star by itself voluntary. The proposed regulations *require* Energy Star compliance:
"If the commission adopts the new rules, beginning in 2011, California retailers would be able to sell only TVs that meet the guidelines of the voluntary federal Energy Star program."
Sounds good to me.
For the record: Google Earth and Google Sketchup have true native ports to Linux. Google Picasa used Wine for its port; it's the only one that uses any kind of compatibility layer, I think. (Disclaimer: although I work on Chrome, and worked on Picasa, I'm speaking for myself, not the company.)
Here are a few notes I wrote a while ago on the subject:
http://kegel.com/academy/opensource.html
http://kegel.com/wine/sweng/ might also be of some interest.
You can use the Google repository, too; see
http://google.com/linuxrepositories
In fact, the .deb for Chrome *adds the google repository*,
so you get updated automatically.
The Google and ppa versions are likely to be very similar.
The main difference at the moment is the icon.
Several approaches are being investigated; see
http://code.google.com/p/chromium/wiki/LinuxSandboxing
http://lwn.net/Articles/332974/
http://www.imperialviolet.org/2008/11/27/sandboxing-on-linux.html
Hey Max,
I am totally a fan of your DIB engine work. It's been
wonderful watching you attack this difficult job.
I do hope you're able to see it through to the end!
- Dan
The original poster is essentially expressing frustration at the slow pace of Wine development. The direct antidote to that general problem is more wine developers.
For the specific case of the DIB engine, we need to free up quite a bit of e.g. Huw and/or Alexandre's time. I'm sure they'd love to work on this, but they have to eat. If you don't want to become a wine developer, perhaps you could raise the needed cash to get a DIB engine integrated. Jeremy White had Huw give it a shot with some support from Google. He had to stop after something like 10^5 $ because it wasn't an obvious win yet, and the end wasn't in sight.
Once Max has demonstrated code that has the needed performance, it'll be time to try to clean it up to Alexandre's standards. Since Max doesn't want to do that, and no developer is stepping up to the plate to try it (maybe somebody could convince Jesse?), it might be worth it for somebody to fund another push. If you aren't a developer, you could help by raising oh, say $50K to let Huw and Alexandre get started on this once it's time. It's not clear that would be enough to finish, but it would let them focus on it for a while.
You're absolutely right that Wine would benefit from more developers.
Would you like to help? See winehq.org/devel for info on how to get started.
I'm one of the Picasa for Linux developers (though I work on Chrome for Linux now), and I was also the release manager for Wine 1.0.
Picasa for Linux does not use Winelib, it uses Wine. We run the exact Windows binary without recompilation. There is very little reason to use winelib when porting a Windows app to x86 Linux.
Earth for Linux is a native app, it does not use Wine at all.
And while we're on the subject of Wine: two big reasons Wine is still important are:
Now, on to Max's DIB engine: he's doing a great job, and I have faith that the Wine maintainer is also doing a great job at keeping Wine healthy. The bar for inclusion of a patch in Wine is very high, and that's a good thing. Many developers get frustrated by Alexandre's relative lack of feedback, but imagine yourself in Alexandre's shoes; he would get overwhelmed if he held everybody's hands. Max's DIB engine is a great prototype. If he can get it to the point where it passes all tests, doesn't cause performance regressions, and does yield large performance improvements for important apps, the core Wine devs *will* take it, clean it up (which might involve rewriting large parts of it), and integrate it -- once they get time/funding to do so. They want a good DIB engine very badly, but not badly enough to do a rush job or neglect their paying customers. Writing and/or integrating a DIB engine is a huge job. We owe Max and those who went before him (Jesse, Huw, ...) a lot for getting things
this far. There's lots left to do, and I hope Max keeps plugging
away, and that others join in.
I am really looking forward to seeing what happens.
I was in a study about nine years ago in which I was given norplant implants plus weekly testosterone injections. (I think I was in Group 4 of this study or a very similar one.) The injections were annoying but not painful; I self-injected in large leg muscles (front or back). It was effective (my sperm count went to zero) and reversible (we conceived without difficulty a year or so later).
HOWEVER, the effect on my mood was not pleasant. To me, it seemed like the world was a less reasonable place. To others, it seemed like I was more irritable and less fun to be around. I don't recommend the experience!
Try the new beta version. The text displays properly there.
There are daily builds you could try. They're pre-alpha, though, so don't expect too much yet. Or you could build it from source, it's not too hard. See http://chromium.org/
I have a better idea: let's take the $10 million and hire programmers to fix the open bugs in Wine. There are about 5000 open bugs, and the stock estimate for cost of fixing the average bug is $2000, so it works out nicely. How 'bout we all write letters to our congressmen to propose the idea?