if it's not, they should complain to their vendor and if the vendor decides there is no need to provide good service because the customer is already locked in?
1: The same soname is kept until the library author makes a change that stops older applications from working. So you can (in theory) upgrade the library safely but you still have to be carefull about the possibility of stupid installers downgrading it.
2: library authors do sometimes make breaking changes without changing the soname. When they do so it puts distro makers (especially those that belive in distributed development like debian) in an awkward position. They either have to break compatibility with thier own older binaries or break compatibility with binaries built on other distros.
3: Library authors often make changes without changing the soname that while not effecting specified behavior do fix bugs that some applications may be relying on. Symbol versioning can sometimes solve this issue but only if the library authors know they are breaking undocumented functionality.
So the *nix situation is better than on windows one but still far from perfect.
afaict there are two types of OEM windows xp, generic oem (shipped with a real windows CD) and big brand oem (shipped with the makers recovery CD).
and if you try to use a big brand OEM key with a generic CD then as you say it will install but you will have to ring microsoft and persude them to activate it.
another good reason to avoid buying from big brands!
fine until you wan't to use something the distro hasn't packaged (or at least hasn't packaged the version of that you wan't) and then you are into finding compilation header packages, compiling from source and then searching for how to edit the menus so you can easilly launch it.
all in all a fairly complex process that most normal users would find very intimidating.
projects like autopackage are trying to improve this but they meet huge resistance from the distros (possiblly because the centralised package distribution systems are what the distros differentiate themselves by).
chp is ok when you need quite a bit of low quality heat (e.g. heating buildings) and some power would be nice too and as you say for true chp you need localised generation.
but i see several major issues with it 1: what do you do in midsummer? (assuming you aren't somewhere cold enough to use heating all year round) i can't imagine chp plant will be very efficiant when its being used as pure power plant 2: you are probablly going to control the chp plant for its heat output so you get the same issues as renewables, namely what do you do with excess leccy (this is actually somewhere where hydrogen electrolosis for vehicle fuel could help as it could be easilly controlled based on the power demand of the grid)? 3: most people wouldn't wan't to be fagged with loading up solid fuel and the control systems would be tricky. Deisel and petrol are very expensive fuels. That just leaves natural gas which is very awkward to transport and the first world is running out of local supplies of.
i'd guess that the copies of dos probablly aren't legal or at least won't be soon, i just can't see there being enough surplus copies still arround to make that sustainable given the massive market growth thats happened in recent times.
remember that MS didn't have all the fancy holograms or serial number tracking systems back in the dos days so its presumablly easy to make convincing pitate copies
but what has happened to me is that an app is upgraded to a new major release that uses a different configuration format, etc., and requires effort on my part to make it work the way it did before. i consider that to be breaking.
yes it doesn't happen too often but i still wouldn't wan't to risk a server.
also while your right its not that much effort for one box i wouldn't wan't to maintain more than a couple of testing boxes.
All secure-testing did is try to get security updates to those on the testing treadmill faster. you still have to either stay on the upgrade treadmill to make use of them (mixing bits from testing a few months apart can be a very bad idea).
Noone is going to provide security updates targeted at where testing was a couple of months ago.
the ONLY ways to get timely security support are 1: stay on the upgrade treadmill for testing or unstable (which is a lot of work and has fairly high risk of breaking something at any time) 2: use a stable release 3: make your own stable branch and backport fixes to it (which will be a massive ammount of work especially if you plan to do serious testing of every fix). 4: use the results of someone else who did 3 (e.g. use ubuntu)
1. Get AMD64 release into the main pool, enough already. Don't wait until December or whatever for Etch - just get it done! afaict amd64 is almost totally built in the official sid archive now and should be making its way into etch gradually atm
the amd64 sarge is an unoffical rebuild and won't ever be part of the official archives.
3. Try and trim the releases down to every 12 months (or less!) and drop the "when it's ready" attitude because that just drives people away. i think 12 months is a bit too fast given that the security team don't belive they have the rescources to support 3 versions of debian at once. 18 months or so is probablly about right allowing a year of security support for oldstable followed by a few months of secuirty support for testing in the run up to its release (when people will be doing test migrations etc).
BUT you don't wan't that kind of upgrade treadmill on a production box. And if you don't follow the upgrade treadmill you lose any modicum of security support.
the REAL problem is that most developers run the bleeding edge distros (unlike in the windows world where people test at least down to 2K and often down to 98 or even 95!)
wheras i can't reliablly run recent linux software on woody (which is newer than windows XP!)
running sarge is tenable for the moment but unless debian gets their house in order and delivers a release at least every couple of years then we are going to see the same issues that woody had all over again.
yet they are still distinct from earlier USB devices. Or so it seems to me. i'm pretty sure that just means they were tested for usb compliance when the 2.0 spec was current and doesn't have any technical meaning. I could be wrong though
umm afaict the only real thing differentiating USB 1.1 and USB 2 is the addition of high speed mode.
and even apple doesn't ship keyboards (possiblly they are shipping a built in high speed hub but i bet the keyboard module itself is low speed) mice etc that use high speed mode.
and for another in practice newly allocated memory is generally full of random (actually, "left over") data, not zeroes. you are confusing two levels of alocation.
standard libraries allocate blocks of memory from the OS and then suballocate/reuse memory within those blocks. Depending on thier design they may at some stage release blocks back to the OS as memory use reduces and of course when the program quits the OS recovers its memory pages.
when a standard library alocator reuses memory it indeed doesn't usually zero it.
when the OS reuses memory it has to zero it for security reasons.
afaict by not routing a signal too far before taking it to a register.
the fact there is lots of clock skew between registers on opposite sides of the chip doesn't actually matter too much as long as the clock skew between any two registers that transfer to each other is sufficiantly low.
you should be able to burn them with your normal burner and any reasonablly large supplier of computer stuff should stock em. Specialist CD suppliers certainly will.
they are quite a bit more expensive than regular discs though and don't store anywhere near as much (for a CD its arround 200 megabyte iirc not sure about DVDs)
a distro is considered to be a collection of software rather than once peice thats how the linux distros who include commercial (non-gpl) software get away with it. Also sometimes with buying the traditional distros you were really buying the manuals not the software.
selling a purely free (as in freely copiable/resellable) product is an extremely low margin buisness as you will immediately get undercut so i'd hardly call it commercial software in the traditional sense.
OpenTTD is amazing. I had been pulling my hair out with different virtual machine tools, but having a good open source version of the game is unbeatable! but they fixed all the old dirty tricks (admittedly ttd fixed a lot of those too but there is still one really major one that works in ttd but not openttd).
Slashdot Mirror
if it's not, they should complain to their vendor
and if the vendor decides there is no need to provide good service because the customer is already locked in?
1: The same soname is kept until the library author makes a change that stops older applications from working. So you can (in theory) upgrade the library safely but you still have to be carefull about the possibility of stupid installers downgrading it.
2: library authors do sometimes make breaking changes without changing the soname. When they do so it puts distro makers (especially those that belive in distributed development like debian) in an awkward position. They either have to break compatibility with thier own older binaries or break compatibility with binaries built on other distros.
3: Library authors often make changes without changing the soname that while not effecting specified behavior do fix bugs that some applications may be relying on. Symbol versioning can sometimes solve this issue but only if the library authors know they are breaking undocumented functionality.
So the *nix situation is better than on windows one but still far from perfect.
it can just get the dns server ips through iphlpapi and talk to them directly.
so no real competitive advantage
afaict there are two types of OEM windows xp, generic oem (shipped with a real windows CD) and big brand oem (shipped with the makers recovery CD).
and if you try to use a big brand OEM key with a generic CD then as you say it will install but you will have to ring microsoft and persude them to activate it.
another good reason to avoid buying from big brands!
not to mention much harder
on linux its just one syscall as root and your app can do what it likes with stuff in the IO map.
fine until you wan't to use something the distro hasn't packaged (or at least hasn't packaged the version of that you wan't) and then you are into finding compilation header packages, compiling from source and then searching for how to edit the menus so you can easilly launch it.
all in all a fairly complex process that most normal users would find very intimidating.
projects like autopackage are trying to improve this but they meet huge resistance from the distros (possiblly because the centralised package distribution systems are what the distros differentiate themselves by).
chp is ok when you need quite a bit of low quality heat (e.g. heating buildings) and some power would be nice too and as you say for true chp you need localised generation.
but i see several major issues with it
1: what do you do in midsummer? (assuming you aren't somewhere cold enough to use heating all year round) i can't imagine chp plant will be very efficiant when its being used as pure power plant
2: you are probablly going to control the chp plant for its heat output so you get the same issues as renewables, namely what do you do with excess leccy (this is actually somewhere where hydrogen electrolosis for vehicle fuel could help as it could be easilly controlled based on the power demand of the grid)?
3: most people wouldn't wan't to be fagged with loading up solid fuel and the control systems would be tricky. Deisel and petrol are very expensive fuels. That just leaves natural gas which is very awkward to transport and the first world is running out of local supplies of.
i'd guess that the copies of dos probablly aren't legal or at least won't be soon, i just can't see there being enough surplus copies still arround to make that sustainable given the massive market growth thats happened in recent times.
remember that MS didn't have all the fancy holograms or serial number tracking systems back in the dos days so its presumablly easy to make convincing pitate copies
ever read the linux advanced routing and traffic control howto?
you should be able to throttle by port, user account and a whole manner of other things.
umm what part of my post implied that?
but what has happened to me is that an app is upgraded to a new major release that uses a different configuration format, etc., and requires effort on my part to make it work the way it did before.
i consider that to be breaking.
yes it doesn't happen too often but i still wouldn't wan't to risk a server.
also while your right its not that much effort for one box i wouldn't wan't to maintain more than a couple of testing boxes.
All secure-testing did is try to get security updates to those on the testing treadmill faster. you still have to either stay on the upgrade treadmill to make use of them (mixing bits from testing a few months apart can be a very bad idea).
Noone is going to provide security updates targeted at where testing was a couple of months ago.
the ONLY ways to get timely security support are
1: stay on the upgrade treadmill for testing or unstable (which is a lot of work and has fairly high risk of breaking something at any time)
2: use a stable release
3: make your own stable branch and backport fixes to it (which will be a massive ammount of work especially if you plan to do serious testing of every fix).
4: use the results of someone else who did 3 (e.g. use ubuntu)
1. Get AMD64 release into the main pool, enough already. Don't wait until December or whatever for Etch - just get it done!
afaict amd64 is almost totally built in the official sid archive now and should be making its way into etch gradually atm
the amd64 sarge is an unoffical rebuild and won't ever be part of the official archives.
3. Try and trim the releases down to every 12 months (or less!) and drop the "when it's ready" attitude because that just drives people away.
i think 12 months is a bit too fast given that the security team don't belive they have the rescources to support 3 versions of debian at once. 18 months or so is probablly about right allowing a year of security support for oldstable followed by a few months of secuirty support for testing in the run up to its release (when people will be doing test migrations etc).
BUT you don't wan't that kind of upgrade treadmill on a production box. And if you don't follow the upgrade treadmill you lose any modicum of security support.
the REAL problem is that most developers run the bleeding edge distros (unlike in the windows world where people test at least down to 2K and often down to 98 or even 95!)
wheras i can't reliablly run recent linux software on woody (which is newer than windows XP!)
running sarge is tenable for the moment but unless debian gets their house in order and delivers a release at least every couple of years then we are going to see the same issues that woody had all over again.
Not all USB 2 devices are hi-speed
indeed
yet they are still distinct from earlier USB devices. Or so it seems to me.
i'm pretty sure that just means they were tested for usb compliance when the 2.0 spec was current and doesn't have any technical meaning. I could be wrong though
umm afaict the only real thing differentiating USB 1.1 and USB 2 is the addition of high speed mode.
and even apple doesn't ship keyboards (possiblly they are shipping a built in high speed hub but i bet the keyboard module itself is low speed) mice etc that use high speed mode.
and for another in practice newly allocated memory is generally full of random (actually, "left over") data, not zeroes.
you are confusing two levels of alocation.
standard libraries allocate blocks of memory from the OS and then suballocate/reuse memory within those blocks. Depending on thier design they may at some stage release blocks back to the OS as memory use reduces and of course when the program quits the OS recovers its memory pages.
when a standard library alocator reuses memory it indeed doesn't usually zero it.
when the OS reuses memory it has to zero it for security reasons.
assuming they actually have a workable product which i very much doubt
the beauty of the web is a huge ammount of interlinked content including the experiances of others who actually attempt similar things to you.
well the fact intel make so many arm CPUs is probablly a result of the fact they don't really have an in house competitor to it.
arm is an "ip" company and afaict always has been. They do designs which manufactures license and produce.
afaict by not routing a signal too far before taking it to a register.
the fact there is lots of clock skew between registers on opposite sides of the chip doesn't actually matter too much as long as the clock skew between any two registers that transfer to each other is sufficiantly low.
any idea how the non-mmu ports of linux handle forking?
i was under the impression that forking required two processes to be able to have the same locations point at independent memory.
you should be able to burn them with your normal burner and any reasonablly large supplier of computer stuff should stock em. Specialist CD suppliers certainly will.
they are quite a bit more expensive than regular discs though and don't store anywhere near as much (for a CD its arround 200 megabyte iirc not sure about DVDs)
a distro is considered to be a collection of software rather than once peice thats how the linux distros who include commercial (non-gpl) software get away with it. Also sometimes with buying the traditional distros you were really buying the manuals not the software.
selling a purely free (as in freely copiable/resellable) product is an extremely low margin buisness as you will immediately get undercut so i'd hardly call it commercial software in the traditional sense.
OpenTTD is amazing. I had been pulling my hair out with different virtual machine tools, but having a good open source version of the game is unbeatable!
but they fixed all the old dirty tricks (admittedly ttd fixed a lot of those too but there is still one really major one that works in ttd but not openttd).
my experiance is that bzip2 is great for things like source archives but on a lot of other data rar beats it.