Okay, I agree in case this is really going to live at www.google.com - I didn't have time to look at the details but also spotted reference to googleapis.com, which is a different story, DNS-wise.
And on the other hand, the extra DNS queries necessary to download the file from a third-party server _reduce_ the responsiveness, often severely. I too often wait for a page to finally show anything while my browser tries hard to resolve google-analytics.com, some obscure polish servers or an ad server. (I would actually say that DNS latency is much underestimated and one of the worst contributing factors to web-browsing latency. Not that I would have that much trouble with it, but when it happens, it's damn noticeable, and it does not happen that rarely.)
For heavy user of many AJAX sites, this might be some improvement. But for casual users, this will in fact cause _additional_ delays.
Would you hold Wine responsible for bugs or use of undocumented internals in the programs that do not run?
If the applications are wide-spread, for that matter, yes, I would. Wine's point is not to emulate ideal Windows environment but to make Windows apps run on Linux, and if working around bugs in them that don't show in Windows is what it takes too, it should do it. Microsoft also does plenty of regression testing when making new version of Windows, often adding workarounds for widespread older apps - in that case it's controversial but Wine is even more clear-cut here.
If it's just about implementing the documented APIs, that shouldn't be that hard after all, but that's not where the devil is, I believe.
(i) Non-obvious usage issues. No documentation is perfect and you might need to do something obscure that isn't well documented, and want to be told how to do it.
(ii) Bugs. If you are depending on MySQL and discover some nasty bug, you need the vendor to fix it and fix it soon. This is the major reason why companies purchase support.
Nope - the AI itself became the trouble, not the men. This is obvious from the "apocryphal" Dune books by Anderson and Herbert Jr., but I think that it should be clear even from the canon books by Herbert itself, IIRC.
Besides, how is the registry poking mind-bogglingly complex? You are just asked to add a bunch of registry keys? I haven't had Windows installed on my computer for the last 7 years but I have always assumed they are to Windows users like text config files for Linux users? And for non-technical users, I'd guess that editing the registry on Windows is about as complex (or just slightly more) as editing config files on Linux. And if you hit some obstacle or want to do something non-standard with your Linux system, getting dirty with your dot or/etc files _is_ what it's gonna come down to. So what's the big fuss here?
You have forgotten to mention the bugzilla numbers of the bugs.
Re:Wine breaks backward compatibility a lot.
on
Wine 0.9.44 Released
·
· Score: 4, Interesting
Actually, this was my experience in the past as well, but during the 0.9 series
this got a lot better for me and now for a long time already I didn't need to
change any actual wine settings for specific application at all (and I'm
messing with relatively wide variety of applications and games. At most I have
to tweak (e.g. graphics) settings of the application itself. New versions don't
break apps that previously were working that much either (though it happens
sometimes; I still have bisecting what broke SC3000 in my long TODO list;).
1. Try. Make the environment cleaner in the process and more friendly to other species. Develop technologies that will also help human survive the hotter environment as a side effect.
2. Don't try. Either hope maybe - just maybe - it's not happenning at all or that all the effort is useless anyway. Blindly carry on as far as possible without inconvenciencing oneself and either get *really* lucky and all the statistical data was just an error, or die happily as one of the two hundred last humans on the Earth.
Well... I guess it's a question of personal values and philosophy.
(The bottom line is: how does it matter if humans actually were the major cause, and how does it make it bad to try to reduce human environmental impact? So if it's 50-50 (very optimistic for you) we still have answer that works great in _both_ cases, so why still argue against it?)
"For instance, existing Windows 3.1 public terminals used a program called Deepfreeze that rebooted the system at the end of each session, something that had to be re-engineered for Linux"
He's kidding, put a line in.bash_logout 'shutdown -r 0 now' and that's it. And besides which, why do you need to reboot at logout.
Perhaps because the reboot was just something they needed to do to achieve something else on Windows 3.1? And with a more usable system they *gasp* needed to figure out how to do it better on Linux?
"Staff also found that the OS was storing information about the contents of public users' removable media, and for privacy purposes had to develop a script to delete this information"
Like where and how, Linux mostly uses/tmp to store temp files all you have to do is add another line to.bash_logout 'find/tmp/ -user $user -exec rm -r {} \;'. Or else put/tmp in a ramdisk and flush it to logout.
And that will flush all the buffers with data from the media and pages left in the swap partition from programs crunching on the data. Yeah.
What you were quoting is pretty clearly not a technical description but something simplified for general public. It's entirely likely that the most interesting technical challenges weren't mentioned at all since they wouldn't be easily sold to the public.
AFAIK Suse 9.3 has only security patches released. For a comparable product with other bugfixes released as well, you want to look at the "enterprise" version of the distribution, in this case SLES9 (or SLED10).
glibc will move to GPL3, but will the Red Hat glibc developers (which do practically all the development nowadays) move to GPL3 as well? (I'm not saying either - Red Hat might or might not go for GPL3, both cases for valid reasons. It's just that people are handwaving about FSF but it's the developers who matter, and whether they will follow the lead. And like it or not, the core GNU tools are mostly developed by corporate-sponsored developers nowadays.)
Er, (2) is sort of how progress is made, isn't it? As long as the format is extended in a proper way and Microsoft doesn't prevent others from implementing it e.g. by patenting the extensions, I can't see anything wrong on it. Then if competitors care about interoperability with Microsoft, they have to keep up with their competition, as simple as that. Furthermore, given (1) the dominant marketshare prerequisite of (3) isn't all that granted either.
I think the main point is that you don't have to worry about batteries going low; also it should be pretty resistent. So you can take it for a few-days trip to the mountains and read a book on it under a tree. Take the wifi into an account, you meet with a friend and can trivially exchange photos from your mountain trip with him or whatever, without being in reach of internet connection. It's not gonna be super-duper multimedia manager notebook but that doesn't mean it's not gonna be extremely practical, perhaps more than the super-duper multimedia manager notebook since for once you actually do something innovative instead of just cranking up the processor speed, amount of RAM and amount of buzzwords.
I've rather meant that if say some "smart TV box" vendor takes MythTV, polishes its features and puts it on a DRM'd hardware, the MythTV guys will still be able to take the vendor improvements and integrate them in the stock MythTV version. Of course you'll be still stuck with the vendor MythTV version on your DRM'd smart TV box, but that's _your_ fault you went for crappy hardware, just as it would be your fault if you complained after you went for closed software on no-matter-how-cool hardware. The net community benefit still raises.
I don't say bad DRM is good thing or not a danger. But fighting it by changing software licence is not the way. You are fighting it in the wrong field and you are actually not likely to win, since the big corporations want DRM that badly that they won't care about GPLv3 software and rather invest in going some other way; alternatively, they may not have a choice in the first place and the restriction is placed by law or a regulation authority (think FCC in the case of the scanner).
Or look for it from another way. Suppose a DVD drive vendor made a driver supporting some cool features, and now you are thinking about releasing drivers for a GPLv3 OS. But GPLv3 says you can't unless you make your DVD drive region-free. *Bang* Of course if the OS was in the position that the market base lost for the vendor would overshadow the losses coming from ruined bussiness relations and likely contract breaches, having that would be good thing, but that's not the case at all.
Alternatively, you can just say "screw corporate support". But please face it, huge amount of the free software development is now backed by corporations and without their support, Linux would be far from where it is today.
I think Linus' got it right when he pointed out the important difference here. GPLv2 is reasonable since it requires that you keep your software free. But with GPLv3 you are crossing the hardware/software line and start making requirements about the _hardware_ the software can run on. But if the hardware has technical restrictions, that's hardware problem, not software problem, and it shouldn't thus have place in a software licence. If your hardware is broken in such a way, go and get (buy/build/...) different hardware and run the software on that.
Clear semantics and syntax reduces flexibility. This way it can be better applied to very diverse scale of real-world situations, based on the judge's judgement of the "spirit" of the law. Of course the cynical self must add "applied in a way sought by the party with a better lawyer", but I believe that in reality it's usually not really nearly that bad.
I guess none if it's really open-source?
Okay, I agree in case this is really going to live at www.google.com - I didn't have time to look at the details but also spotted reference to googleapis.com, which is a different story, DNS-wise.
And on the other hand, the extra DNS queries necessary to download the file from a third-party server _reduce_ the responsiveness, often severely. I too often wait for a page to finally show anything while my browser tries hard to resolve google-analytics.com, some obscure polish servers or an ad server. (I would actually say that DNS latency is much underestimated and one of the worst contributing factors to web-browsing latency. Not that I would have that much trouble with it, but when it happens, it's damn noticeable, and it does not happen that rarely.)
For heavy user of many AJAX sites, this might be some improvement. But for casual users, this will in fact cause _additional_ delays.
If the applications are wide-spread, for that matter, yes, I would. Wine's point is not to emulate ideal Windows environment but to make Windows apps run on Linux, and if working around bugs in them that don't show in Windows is what it takes too, it should do it. Microsoft also does plenty of regression testing when making new version of Windows, often adding workarounds for widespread older apps - in that case it's controversial but Wine is even more clear-cut here.
If it's just about implementing the documented APIs, that shouldn't be that hard after all, but that's not where the devil is, I believe.
You, sir, have apparently never geocached. My $75 GPS can be accurate up to 3m in very favorable conditions, and 5m-9m accuracy is normal.
You need support for:
(i) Non-obvious usage issues. No documentation is perfect and you might need to do something obscure that isn't well documented, and want to be told how to do it.
(ii) Bugs. If you are depending on MySQL and discover some nasty bug, you need the vendor to fix it and fix it soon. This is the major reason why companies purchase support.
Nope - the AI itself became the trouble, not the men. This is obvious from the "apocryphal" Dune books by Anderson and Herbert Jr., but I think that it should be clear even from the canon books by Herbert itself, IIRC.
Besides, how is the registry poking mind-bogglingly complex? You are just asked to add a bunch of registry keys? I haven't had Windows installed on my computer for the last 7 years but I have always assumed they are to Windows users like text config files for Linux users? And for non-technical users, I'd guess that editing the registry on Windows is about as complex (or just slightly more) as editing config files on Linux. And if you hit some obstacle or want to do something non-standard with your Linux system, getting dirty with your dot or /etc files _is_ what it's gonna come down to. So what's the big fuss here?
You have forgotten to mention the bugzilla numbers of the bugs.
Actually, this was my experience in the past as well, but during the 0.9 series this got a lot better for me and now for a long time already I didn't need to change any actual wine settings for specific application at all (and I'm messing with relatively wide variety of applications and games. At most I have to tweak (e.g. graphics) settings of the application itself. New versions don't break apps that previously were working that much either (though it happens sometimes; I still have bisecting what broke SC3000 in my long TODO list ;).
So the choice is:
1. Try. Make the environment cleaner in the process and more friendly to other species. Develop technologies that will also help human survive the hotter environment as a side effect.
2. Don't try. Either hope maybe - just maybe - it's not happenning at all or that all the effort is useless anyway. Blindly carry on as far as possible without inconvenciencing oneself and either get *really* lucky and all the statistical data was just an error, or die happily as one of the two hundred last humans on the Earth.
Well... I guess it's a question of personal values and philosophy.
(The bottom line is: how does it matter if humans actually were the major cause, and how does it make it bad to try to reduce human environmental impact? So if it's 50-50 (very optimistic for you) we still have answer that works great in _both_ cases, so why still argue against it?)
If you want it, patch it or pay someone to patch it for you.
That's the choice you get with opensource.
I agree, I also feel that I have been getting deja vu more frequently in my childhood. My brain sure got much lazier over the years.
AFAIK Suse 9.3 has only security patches released. For a comparable product with other bugfixes released as well, you want to look at the "enterprise" version of the distribution, in this case SLES9 (or SLED10).
glibc will move to GPL3, but will the Red Hat glibc developers (which do practically all the development nowadays) move to GPL3 as well? (I'm not saying either - Red Hat might or might not go for GPL3, both cases for valid reasons. It's just that people are handwaving about FSF but it's the developers who matter, and whether they will follow the lead. And like it or not, the core GNU tools are mostly developed by corporate-sponsored developers nowadays.)
Er, (2) is sort of how progress is made, isn't it? As long as the format is extended in a proper way and Microsoft doesn't prevent others from implementing it e.g. by patenting the extensions, I can't see anything wrong on it. Then if competitors care about interoperability with Microsoft, they have to keep up with their competition, as simple as that. Furthermore, given (1) the dominant marketshare prerequisite of (3) isn't all that granted either.
I think the main point is that you don't have to worry about batteries going low; also it should be pretty resistent. So you can take it for a few-days trip to the mountains and read a book on it under a tree. Take the wifi into an account, you meet with a friend and can trivially exchange photos from your mountain trip with him or whatever, without being in reach of internet connection. It's not gonna be super-duper multimedia manager notebook but that doesn't mean it's not gonna be extremely practical, perhaps more than the super-duper multimedia manager notebook since for once you actually do something innovative instead of just cranking up the processor speed, amount of RAM and amount of buzzwords.
In what form?
Hmm, and how will you ship payloads into orbit with a suborbital flight?
I've rather meant that if say some "smart TV box" vendor takes MythTV, polishes its features and puts it on a DRM'd hardware, the MythTV guys will still be able to take the vendor improvements and integrate them in the stock MythTV version. Of course you'll be still stuck with the vendor MythTV version on your DRM'd smart TV box, but that's _your_ fault you went for crappy hardware, just as it would be your fault if you complained after you went for closed software on no-matter-how-cool hardware. The net community benefit still raises.
I don't say bad DRM is good thing or not a danger. But fighting it by changing software licence is not the way. You are fighting it in the wrong field and you are actually not likely to win, since the big corporations want DRM that badly that they won't care about GPLv3 software and rather invest in going some other way; alternatively, they may not have a choice in the first place and the restriction is placed by law or a regulation authority (think FCC in the case of the scanner).
Or look for it from another way. Suppose a DVD drive vendor made a driver supporting some cool features, and now you are thinking about releasing drivers for a GPLv3 OS. But GPLv3 says you can't unless you make your DVD drive region-free. *Bang*
Of course if the OS was in the position that the market base lost for the vendor would overshadow the losses coming from ruined bussiness relations and likely contract breaches, having that would be good thing, but that's not the case at all.
Alternatively, you can just say "screw corporate support". But please face it, huge amount of the free software development is now backed by corporations and without their support, Linux would be far from where it is today.
I think Linus' got it right when he pointed out the important difference here. GPLv2 is reasonable since it requires that you keep your software free. But with GPLv3 you are crossing the hardware/software line and start making requirements about the _hardware_ the software can run on. But if the hardware has technical restrictions, that's hardware problem, not software problem, and it shouldn't thus have place in a software licence. If your hardware is broken in such a way, go and get (buy/build/...) different hardware and run the software on that.
And what exactly is disastrous about it? According to the timeline it is alive and nothing hints about any disasters...
Well, perhaps if you consider yourself disabled because of using Firefox...
Clear semantics and syntax reduces flexibility. This way it can be better applied to very diverse scale of real-world situations, based on the judge's judgement of the "spirit" of the law. Of course the cynical self must add "applied in a way sought by the party with a better lawyer", but I believe that in reality it's usually not really nearly that bad.