However, wealth (the non-abundant variety) always ultimately flows upward. It loops downward a lot, but the net effect over time is that more and more wealth gets concentrated among smaller and smaller groups of people. Such movement is not indefinitely sustainable, so all economies collapse eventually.
Time series over the gini income coefficient (higher number means the rich are richer, so to speak) do not indicate this. At least, eyeballing the graphs does not reveal any trends for me. I know, this is just the income.. it would be nice if someone would care to do the graphs for the gini coefficent of the wealth directly.
As long as the market expects the devaluation of the fiat currency, your interest rate will reflect this devaluation. So if the market is a perfect predictor, your bank account will stay constant with regard to gold (the market would have to predict gold extraction rate perfectly, too, of course). Of course, if the market is too optimistic, you will loose money, and too pessimistic you will gain.
Remember, it's all in our head: Gold only has value because people think it has, outside of a few industrial processes. It works because enough people have faith that this state of affair will continue. Exactly like fiat currencies like the dollar: As long as enough people wants dollars to keep the worth up, it will continue to work. The difference is that the American government (or whoever makes those decisions on that side of the pond) decides to devaluate the dollar 10-fold, that faith will take a severe hit, and the market expectation would cause the interest rate for loan in dollars to go up significantly for a time, until the market is convinced that it won't happen again. Of course, that can't happen with gold, but then you don't get interest either.
Stocks, foodstuff, oil... these things a bit different.
They've never been popular in the LInux world because Linux users have typically been willing to deal with the extra adminitrative overhead of package management and lack of proprietary software. But Linux users are not typical users and they never will be.
Again, what overhead? Lack proprietary software is, on the other hand, an issue, but it has nothing to do with Debian, but with the installed base. Max OS X is another that suffers from the latter, if to a lesser degree.
You don't need a "huge" base. You only needs a sufficiently robust base., which you have with OS X. You're speaking in purely theoretical terms. Open your eyes. OS X is a nice system to use and work wth.
You can chose between huge or constantly reinventing and reimplementing stuff. OS X does not satisfy my requirements for being highly productive (e.g, I need to have all the source code for the operating system and libraries I use available in a convenient way). If I were to use something else, it would be windows, because I like computer games. (Unfortunately, I have little time for those currently) . OS X is the worst of both worlds: Little proprietary software, and no sources.
I have dozens of proprietary programs on this computer, mainly games.
Dozens, huh? And you're telling me the all just worked? Bullshit. Oh wait, I bet this is where you say something like "excluding bugs" or "I only had to do a few tweaks to make it work." Or some qualifier like that. You've never had to backport a program or fiddle with getting a package you want from one distribution to work on yours? I dealt with all of it on Linux and it SUCKED.
Yes, they all just worked. No fiddling, I have no time for that anymore. Why shouldn't they? If a program I bought didn't work, I would write the publisher and ask him to either fix it or refund me. What else can you do, whatever the system? And yeah, I gather you were burned once.
The problem with bundling programs on Linux is that you have to bundle far more shared libraries than you would on OS X because a developer can't expect you to have anything but the most basic libraries like libc. So it is no wonder you have such a lower opinion of bundling. Your experience with it is on Linux, a system that doesn't explicitly support bundling.
The LSB describes what is there, and the rest must be bundled. What does it matter if I have to bundle 6 libraries rather than 4? The work is pretty much the same. And as I demonstrated above, a huge base is not desirable. We can discuss where exactly the line should go, but I doubt there really is a perfect line.
We need to know, so that we can tick off the checkbox that says "working in 32-bit". As an old sysadmin, I presume you are familiar with the fact that going from 64-bit to 32-bit can break stuff, just like the other way?
On Linux, yes, but I never had a problem on OS X. That's what I'm trying to tell you.
lol. I got to try that. "No dear customer we didn't test on 32-bit like you asked. Why? Oh, we use Macs, we don't need to test, you see. What? No money? Why not?
A harmless bug might suddenly not be so harmless when you change the word-length, you know? Had we used Macs, we would have to do the exact same thing. My point was that unless you actually query the system in some way, it's hard to tell. Seems very seamless to me.
You just went over how you have to use schroot to setup a full 32bit environment and you're going to sit there and tell me that it is seamless?
I said, if you would listen, that I preferred to use a 32-bit schroot for testing that, because then I am sure it works the way I want to. It is very easy to setup and maintain such a schroot... one short line on the prompt, and voila. I could also, like I wrote, have done this inside m
A much better way to handle this is to limit the number of messages per hour that can be sent from a newly created account. Then if it takes a day, or three days, to shut down a spam account, the consequences aren't that bad; the spammer can't use the account to send a million emails in 24 hours. I assume that gmail and yahoo already do this kind of rate-limiting.
That wouldn't work very well. The spammer would just sign up for a lot of email accounts instead. Or rent a server, linode is like $20 for a month, and I bet you can send a lot of spam before it is shut down.
Ok, I will try to restate the points you apparently cannot see.
I'll take a system that puts user experience ahead of developmental purity, thanks. No excuses necessary.
It is OS X that puts user experience over developer (OS X developer) convenience. Automatic dependency resolving is some work, which you sidestep by bundling. Bundling costs the user, in terms of security and in terms of performance (esp. less memory). That is why they have never been popular in the Linux world. Of course, both of these are sneaky problems, which only eats at you in tiny nipples.
I'm sure it depends entirely on what I'm writing. Most software out there can rely on base and include libraries. And when they can't, they can just bundle what they need at very little real cost to the user. The trick is to provide a sufficiently robust base.Something that LInux has utterly failed to do. So it is understandable that you might not think much of "base" systems.
If you have a huge base, you will be dragging along crap for a long time, because any library you put in the base has to be supported forever unless you want to break contract on that base. And any libraries accumulate cruft, stuff that wasn't designed as well as should be, or rested on assumptions that at no longer true. (e.g, who would have thought that users routinely had 2 or more sound cards on their desktop, or 2 graphics cards, just 10 years ago?) Not a good idea, tempting as it might be. Better to have a small base, an automatic, transparent dependency resolving (like Debian provides).
On Linux you can't even rely on the user having certain GUI libraries installed beyond the basic X11 libraries. Aren't there like a half dozen different ways to play sound on Linux? It is is a disaster, if you ask me.
Why should that matter? When I install say Krita, all the libraries I need are automatically installed if necessary, just as they are automatically updated if needed. I don't *care* what libraries people use to write their software, because I don't need to.
I already went over why it is crude. It has at least 2 problems: Security, and resource waste. Problems solved for decades om linux
Disk space is cheap and security hasn't been an issue. I don't see the problem.
That would be because you do not know much about how shared libraries work. It is not only disk space that you waste, it is also memory. Oh yeah, sure, it is cheap also;) Excuses upon excuses for a lazy, crude design.
Oh, don't worry, I totally understand where you're coming from. I was like you for the longest time. I would make all kinds of excuses for Linux when people complained about the lack of commercial software
You would be the one with the excuses for the primitive bundling technique, widespread in commercial software, also on linux. I am pointing out how the automatic dependency resolving is better, because it means applications use less memory, less disk space and are more secure, while being transparent or nearly so for the user.
or how complicated it was to do simple things like print (I realize it has gotten better).
shall I bring up the one button mouse, or the braindead no-eject-button on the diskette drive? Much the same age. Not only are they solved problems, they are also completely unrelated to installation of applications, which is what we were discussing. Why don't you just admit you were wrong?:)
I'd just rattle off the "easy" commands to do it.
I bet you would. Not something I have ever done. The shortcomings of linux are plenty, but that packaging system is a strength, not a weakness.
And to me that was sufficient because I was a system administrator and part time programmer at the time.
Some shared libraries are copied, but since OS X is a predictable base system, you don't actually have to bundle most things. And the things you do bundle are likely not used by anthing else anyway. So they're non-issues. I used LInux for 10 years and I'll tell you, bundling eliminates so much hassle. Packages are fine for the base system, but user applications need to be much more flexible. Most Linux distributions are just big monolithic beasts where every damn application is tightly coupled with the next.
Only poor developers only depends on included shared libraries, and yes, the remaining libraries could be reused. You are just making excuses for a crude system.
So it might look like a good idea to someone who doesn't know much about the subject,
LOL. Wow, dude. I'm a developer myself. I know what I'm taking about.
If you think that base and included libraries are sufficient for any real work, you are not a very good developer. You will be taking much longer, with a lot more bugs, than if you used existing libraries extensively.
Yea... not quite the same.
Since you cannot tell me what the difference is, exactly, I'll assume that yes, it is quite the same except for the cool-aid.
Crude? What's crude about allowing multiple architectures to be bundled into a single file? It worked perfectly. How would it not work for architectures besides PPC and x86? You're blustering.
I already went over why it is crude. It has at least 2 problems: Security, and resource waste. Problems solved for decades om linux
The specific problem of coexisting 32 and 64 bit has been working in Debian for many, many years.
It has worked, but not seamlessly or we wouldn't have so many LInux users complaining about things like Adobe Flash.
Those complains were about Adobe not releasing 64-bit on linux before long after the other platforms. No distribution magic will cure that problem, and it would also have been a problem on OS X.
And it doesn't work completely. Debian provides i386-libs, but if you happen to have a piece of software that needs a library not included in that rather limited set, you're SOL.
Hardly. You have several options from there. Personally, being a developer, I maintain a complete 32-bit environment to reproduce those bugs that only shows up on 32-bit. This is very easy with the schroot package. Or if you prefer, you could install the missing libraries, and use the (crude) OS X solution, like you normally do with proprietary software (games, e.g.). That is outside the scope of package managers, though.
You never even have to think about how many "bits" your system was on OS X. You never had to worry about whether Firefox was 32bit or 64bit. You simply cannot say that about LInux.
You know, in our company we keep a wiki-page over which systems runs with 64-bit, and which with 32-bit. Because noone can remember, otherwise, and sometimes you need to know. As for how exposed this information is, that is a culture thing. Mac owners don't want to know, linux users do.
I find it totally laughable that you can sit there and criticize how Apple handled things when your only complains are theoretical. In reality, everything worked out quite well.
Resource wastage and security risks are real, but also something that is popular to ignore. I find it sad that you as a developer do not care about those things, but I suppose it is how it is these days.
A problem that Apple solved years ago in a far more elegant way.
No. The dependency problem was unsolved, and only a limited number of architectures. They build a mud hut and you claimed they solved the problem of building skyscrapers. Come on, this is simple facts!
Of course, OS X doesn't handle automatic dependency resolution at all, does it? It relies on bundling instead, wasting resources left and right, if I recall correctly.
Bundling is one of the best parts of OS X, IMO. Who the hell cares if it wastes a bit of disk space? It WORKS. And it is totally hassle free. No installers. No package managers. You just copy the app to your desktop.. and run. Don't want it anymore? Delete it. Want to test two versions of the same software (one beta, perhaps) side by side? Keep both copies. You dont' have to worry about an installer or package manager trying to overwrite the old version. THAT is what computers should be like. OS X handles dependency resolution by making it a non-issue. Disk space is cheap as hell. I'll take a polished, hassle free user experience with some wasted disk space any day.
Bundles means multiple copies of shared libraries. This has 2 implication: 1. the libraries cannot share memory pages and 2. security updates are not applied across the board, meaning that security updates are cumbersome to apply. So it might look like a good idea to someone who doesn't know much about the subject, but it is in fact a rather bad idea. (But if you like it, I have seen a few distribution on package managers on Linux that does this. Not popular, though, for good reasons.)
It is laughable that you can sit there and criticize how Apple handled it when Debian is only JUST NOW seriously addressing the general problem of managing multiple architectures.
Sigh. As I said, it is a problem Apple has never handled. Why should they? You cannot install Apple on many architectures. The solution they chose was an interim solution, and as such the solution was rather crude. The specific problem of coexisting 32 and 64 bit has been working in Debian for many, many years.
This thread is full of Linux users directly or indirectly complaining about how the transition to 64bit has been handled on LInux. Don't tell me it isn't a problem. I've dealt with it myself.
I must have been lucky, then. I never had a problem, excepting bugs in software.
It is customary in the field to use 30-year periods. But you know, it's a null-hyptothesis thing: You set up a wanted confidence (say 1%) and then the null hypothesis (no link between CO2 and global mean temperature) and then run the numbers. I dare you to get to any other result than the scientific community, and publish the result;)
Their loss because it could have made the current 32 to 64 bit transition a lot smoother had it been generally accepted and used. Think one kernel, at least 2 different architectures. Also, it would presumably extend down to the driver level too. You wouldn't even have to think about how many "bits" your system is. Everything would just work. The boot loader would pick the optimal arch and you'd be set. But I guess Linux users don't like things to be too easy. (I was a Linux user for many years, and this was actually the case in many ways).
Everything did just work --- bugs excepted. And do. The problem this is going to solve is "how to handle N architectures on the same installation, dependencies and all. Of course, OS X doesn't handle automatic dependency resolution at all, does it? It relies on bundling instead, wasting resources left and right, if I recall correctly.
While I am not an expert, it seems wasteful to me to load a bunch of architectures you won't ever need,
Define "load." It isn't l like you load all architectures into memory for all executables. They're just there if you need them. Also, I could be mistaken, but I believe the way OS X uses message passing, I don't think all shared libraries need to be multiarch. 32 bit programs can more smoothly interact with 64 bit programs/libraries.
You would be mistaken. Message passing in a architecture-independent way is expensive.
and wasteful to install a bunch of libraries for architectures you don't use. Typically, only a very small part of your installation will actually need to be multiarch. Of course, if I were *also* selling hardware, I might be a bit more wasteful:)
Oh please. Disk space is dirt cheap. That's just an excuse for laziness on the part of developers, packagers, and distribution maintainers.
Oh please. Laziness is just stuffing in everything, that's the banal, ham-fisted solution. That you think that you always have enough disk space shows how little you understand of the range of computer hardware Debian supports. E.g, I have a server that only have 16Gb of hard disk space, and needs most of that space for data. I appreciate not having space wasted because the Debian developers chose the ham-fisted approach.
Meanwhile, Linux users will continue to bitch and complain about things like Adobe Flash not working correctly due to architecture differences. Not properly handling multiarch has a a significant impact on user experience. Linux developers could learn from Apple. But instead, they insist on using Microsoft as the standard by which they measure themselves up to. And Microsoft has had their own 64bit transition problems. So sad.
Obviously, you did not understand what the issue was. Running a 32-bit browser in a 64-bit environment was what flashusers did, but it is suboptimal for a number of reasons.
Bottom line is that Apple managed to not only seamlessly transition from 32bit to 64bit, but also from PPC to x86. You have to give them credit.
lol
Typically, only a very small part of your installation will actually need to be multiarch.
Depends on how broadly you want to support 32 and 64 bit side by side. If you want to do it in the most transparent manner possible, you best make as much of the base system multiarch as possible. The problem with Linux is that there is no real "base" system. A Linux distribution is more or less one monolithic beast with every package tightly coupled with the next. It is kind all or nothing with Linux.
What are you talking about? Broadly support? Dependencies are (of course) resolved automatically. There is no "base system", no limit to the multi-arch support.
Anyway, I'm just saying that this "multiarch" support by Debian seems l
Both solutions are transparent for the user --- it is only something that matters to packagers. Debians solution is also transparent for the developer, though Apple's (I guess) is not, but then, Apple does not have packagers.
This idea (nicknamed "FAT elf") was considered and rejected across the board --- noone wanted it. While I am not an expert, it seems wasteful to me to load a bunch of architectures you won't ever need, and wasteful to install a bunch of libraries for architectures you don't use. Typically, only a very small part of your installation will actually need to be multiarch. Of course, if I were *also* selling hardware, I might be a bit more wasteful:)
In principle, you could run an emulator to run binaries for other architectures with e.g. qemu. I gather that that is not immediately in scope, though.
Lots of theories are settled. To take something uncontroversial, Ohm's Laws are pretty settled. You won't find many any scientists trying to think up experiments to validate these laws. Of course, if someone actually managed to come up with an experiment that could repeatedly disprove the laws in some cases, something might happen --- but most likely, such an experiment would be flawed in some way.
In the same way, you won't find many scientist trying to validate that CO2 heats up the atmosphere by absorbing/reflecting infrared radiation.
Apple chose to bundle all supported (2) architectures in all packages. While wasteful, it was effective given the low number of supported architectures (2). Given that debian support quite a few architectures, that route really isn't feasible. Is it more clear now?
Most of the scientists in climate are not studying the "if", because that question has been pretty much settled for, what, 40 years now? The questions they work on is "how much, how quickly, what distribution". Or at least, that's what I gather from reading the blogs of those scientists.
Should new data emerge that casts doubt on that "if", some will return to look at it. But one swallow doth not a summer make, and all that. This is one study against a mountain of others.
Possibly, but I doubt it. Usually, you are using host names, and all the details are handled by (C or possibly Java) libraries, which means your old applications still works beautifully.
Of course, if you have intranet sites for registering your IP address or setting up a VPN or something like that, that might need an update. But the place where you write your business proposals, maintain your CRM database etc. should just work.
I just took the first one and googled. I didn't find any official announcements, but according to forum messages they plan to have IPv6 ready this year. So next year, maybe?;)
I also suspect that since I have never heard of those companies, except GoDaddy, this is U.S-companies? The U.S. is possibly the country furthest behind in the IPv6-race, excepting Denmark (where I live).
Linode is slowly rolling out IPv6 finally:D
Anyway, today IPv6 is useful already to provide ssh-connectivity (and stuff that uses ssh like git) between developer machines. It's worth the setup cost just for that, in my estimation, even with tunnels.
It's a valid complain, but apparently not easy to fix. Why aren't website designs fluid, so that they scale to to the browser window? Mostly because support for the table-bit of CSS 2.1support is still broken in many modern browsers, I hear. Which makes it hard to get that holy-grail 2/3-column design-with-top-and-button that web designers love.
Try searching their bugzilla.. in this case, that would give you bug 204340, which is indeed fixed and should be part of 4.7.
Re:Each major release is taking longer
on
KDE 4.7.0 Released
·
· Score: 1
How the heck could KDE4(.0) copy Vista?
As for your desktop woes, I think your problem is that you are using Desktop for the usecase Activities were designed to. If you instead of multiple desktop use multiple activities, you can have your wallpapers and your application configured per activity. As a bonus, you could even have some application on more than one (or all) activities, if that makes sense for you.
Re:Each major release is taking longer
on
KDE 4.7.0 Released
·
· Score: 1
Yet other people report stellar performance on low-ends, so it's not clear-cut what is going on --- it could be a defective driver, some application going haywire on you, or a distro problem. I don't own a low-end computer (an Athlon64 is my current lowest-end), and on these KDE works just fine. The 1Gb RAM machine is struggling with the number of facebook tabs my wife wants to put on it, though.
Slashdot Mirror
UFO: AI feels ... different. I'd say in a good way, but don't expect an exact copy.
However, wealth (the non-abundant variety) always ultimately flows upward. It loops downward a lot, but the net effect over time is that more and more wealth gets concentrated among smaller and smaller groups of people. Such movement is not indefinitely sustainable, so all economies collapse eventually.
Time series over the gini income coefficient (higher number means the rich are richer, so to speak) do not indicate this. At least, eyeballing the graphs does not reveal any trends for me. I know, this is just the income.. it would be nice if someone would care to do the graphs for the gini coefficent of the wealth directly.
As long as the market expects the devaluation of the fiat currency, your interest rate will reflect this devaluation. So if the market is a perfect predictor, your bank account will stay constant with regard to gold (the market would have to predict gold extraction rate perfectly, too, of course). Of course, if the market is too optimistic, you will loose money, and too pessimistic you will gain.
Remember, it's all in our head: Gold only has value because people think it has, outside of a few industrial processes. It works because enough people have faith that this state of affair will continue. Exactly like fiat currencies like the dollar: As long as enough people wants dollars to keep the worth up, it will continue to work. The difference is that the American government (or whoever makes those decisions on that side of the pond) decides to devaluate the dollar 10-fold, that faith will take a severe hit, and the market expectation would cause the interest rate for loan in dollars to go up significantly for a time, until the market is convinced that it won't happen again. Of course, that can't happen with gold, but then you don't get interest either.
Stocks, foodstuff, oil... these things a bit different.
They've never been popular in the LInux world because Linux users have typically been willing to deal with the extra adminitrative overhead of package management and lack of proprietary software. But Linux users are not typical users and they never will be.
Again, what overhead? Lack proprietary software is, on the other hand, an issue, but it has nothing to do with Debian, but with the installed base. Max OS X is another that suffers from the latter, if to a lesser degree.
You don't need a "huge" base. You only needs a sufficiently robust base., which you have with OS X. You're speaking in purely theoretical terms. Open your eyes. OS X is a nice system to use and work wth.
You can chose between huge or constantly reinventing and reimplementing stuff. OS X does not satisfy my requirements for being highly productive (e.g, I need to have all the source code for the operating system and libraries I use available in a convenient way). If I were to use something else, it would be windows, because I like computer games. (Unfortunately, I have little time for those currently) . OS X is the worst of both worlds: Little proprietary software, and no sources.
I have dozens of proprietary programs on this computer, mainly games.
Dozens, huh? And you're telling me the all just worked? Bullshit. Oh wait, I bet this is where you say something like "excluding bugs" or "I only had to do a few tweaks to make it work." Or some qualifier like that. You've never had to backport a program or fiddle with getting a package you want from one distribution to work on yours? I dealt with all of it on Linux and it SUCKED.
Yes, they all just worked. No fiddling, I have no time for that anymore. Why shouldn't they? If a program I bought didn't work, I would write the publisher and ask him to either fix it or refund me. What else can you do, whatever the system? And yeah, I gather you were burned once.
The problem with bundling programs on Linux is that you have to bundle far more shared libraries than you would on OS X because a developer can't expect you to have anything but the most basic libraries like libc. So it is no wonder you have such a lower opinion of bundling. Your experience with it is on Linux, a system that doesn't explicitly support bundling.
The LSB describes what is there, and the rest must be bundled. What does it matter if I have to bundle 6 libraries rather than 4? The work is pretty much the same. And as I demonstrated above, a huge base is not desirable. We can discuss where exactly the line should go, but I doubt there really is a perfect line.
We need to know, so that we can tick off the checkbox that says "working in 32-bit". As an old sysadmin, I presume you are familiar with the fact that going from 64-bit to 32-bit can break stuff, just like the other way?
On Linux, yes, but I never had a problem on OS X. That's what I'm trying to tell you.
lol. I got to try that. "No dear customer we didn't test on 32-bit like you asked. Why? Oh, we use Macs, we don't need to test, you see. What? No money? Why not?
A harmless bug might suddenly not be so harmless when you change the word-length, you know? Had we used Macs, we would have to do the exact same thing. My point was that unless you actually query the system in some way, it's hard to tell. Seems very seamless to me.
You just went over how you have to use schroot to setup a full 32bit environment and you're going to sit there and tell me that it is seamless?
I said, if you would listen, that I preferred to use a 32-bit schroot for testing that, because then I am sure it works the way I want to. It is very easy to setup and maintain such a schroot... one short line on the prompt, and voila. I could also, like I wrote, have done this inside m
A much better way to handle this is to limit the number of messages per hour that can be sent from a newly created account. Then if it takes a day, or three days, to shut down a spam account, the consequences aren't that bad; the spammer can't use the account to send a million emails in 24 hours. I assume that gmail and yahoo already do this kind of rate-limiting.
That wouldn't work very well. The spammer would just sign up for a lot of email accounts instead. Or rent a server, linode is like $20 for a month, and I bet you can send a lot of spam before it is shut down.
Ok, I will try to restate the points you apparently cannot see.
I'll take a system that puts user experience ahead of developmental purity, thanks. No excuses necessary.
It is OS X that puts user experience over developer (OS X developer) convenience. Automatic dependency resolving is some work, which you sidestep by bundling. Bundling costs the user, in terms of security and in terms of performance (esp. less memory). That is why they have never been popular in the Linux world. Of course, both of these are sneaky problems, which only eats at you in tiny nipples.
I'm sure it depends entirely on what I'm writing. Most software out there can rely on base and include libraries. And when they can't, they can just bundle what they need at very little real cost to the user. The trick is to provide a sufficiently robust base .Something that LInux has utterly failed to do. So it is understandable that you might not think much of "base" systems.
If you have a huge base, you will be dragging along crap for a long time, because any library you put in the base has to be supported forever unless you want to break contract on that base. And any libraries accumulate cruft, stuff that wasn't designed as well as should be, or rested on assumptions that at no longer true. (e.g, who would have thought that users routinely had 2 or more sound cards on their desktop, or 2 graphics cards, just 10 years ago?) Not a good idea, tempting as it might be. Better to have a small base, an automatic, transparent dependency resolving (like Debian provides).
On Linux you can't even rely on the user having certain GUI libraries installed beyond the basic X11 libraries. Aren't there like a half dozen different ways to play sound on Linux? It is is a disaster, if you ask me.
Why should that matter? When I install say Krita, all the libraries I need are automatically installed if necessary, just as they are automatically updated if needed. I don't *care* what libraries people use to write their software, because I don't need to.
I already went over why it is crude. It has at least 2 problems: Security, and resource waste. Problems solved for decades om linux
Disk space is cheap and security hasn't been an issue. I don't see the problem.
That would be because you do not know much about how shared libraries work. It is not only disk space that you waste, it is also memory. Oh yeah, sure, it is cheap also ;) Excuses upon excuses for a lazy, crude design.
Oh, don't worry, I totally understand where you're coming from. I was like you for the longest time. I would make all kinds of excuses for Linux when people complained about the lack of commercial software
You would be the one with the excuses for the primitive bundling technique, widespread in commercial software, also on linux. I am pointing out how the automatic dependency resolving is better, because it means applications use less memory, less disk space and are more secure, while being transparent or nearly so for the user.
or how complicated it was to do simple things like print (I realize it has gotten better).
shall I bring up the one button mouse, or the braindead no-eject-button on the diskette drive? Much the same age. Not only are they solved problems, they are also completely unrelated to installation of applications, which is what we were discussing. Why don't you just admit you were wrong? :)
I'd just rattle off the "easy" commands to do it.
I bet you would. Not something I have ever done. The shortcomings of linux are plenty, but that packaging system is a strength, not a weakness.
And to me that was sufficient because I was a system administrator and part time programmer at the time.
Some shared libraries are copied, but since OS X is a predictable base system, you don't actually have to bundle most things. And the things you do bundle are likely not used by anthing else anyway. So they're non-issues. I used LInux for 10 years and I'll tell you, bundling eliminates so much hassle. Packages are fine for the base system, but user applications need to be much more flexible. Most Linux distributions are just big monolithic beasts where every damn application is tightly coupled with the next.
Only poor developers only depends on included shared libraries, and yes, the remaining libraries could be reused. You are just making excuses for a crude system.
So it might look like a good idea to someone who doesn't know much about the subject,
LOL. Wow, dude. I'm a developer myself. I know what I'm taking about.
If you think that base and included libraries are sufficient for any real work, you are not a very good developer. You will be taking much longer, with a lot more bugs, than if you used existing libraries extensively.
Yea... not quite the same.
Since you cannot tell me what the difference is, exactly, I'll assume that yes, it is quite the same except for the cool-aid.
Crude? What's crude about allowing multiple architectures to be bundled into a single file? It worked perfectly. How would it not work for architectures besides PPC and x86? You're blustering.
I already went over why it is crude. It has at least 2 problems: Security, and resource waste. Problems solved for decades om linux
The specific problem of coexisting 32 and 64 bit has been working in Debian for many, many years.
It has worked, but not seamlessly or we wouldn't have so many LInux users complaining about things like Adobe Flash.
Those complains were about Adobe not releasing 64-bit on linux before long after the other platforms. No distribution magic will cure that problem, and it would also have been a problem on OS X.
And it doesn't work completely. Debian provides i386-libs, but if you happen to have a piece of software that needs a library not included in that rather limited set, you're SOL.
Hardly. You have several options from there. Personally, being a developer, I maintain a complete 32-bit environment to reproduce those bugs that only shows up on 32-bit. This is very easy with the schroot package. Or if you prefer, you could install the missing libraries, and use the (crude) OS X solution, like you normally do with proprietary software (games, e.g.). That is outside the scope of package managers, though.
You never even have to think about how many "bits" your system was on OS X. You never had to worry about whether Firefox was 32bit or 64bit. You simply cannot say that about LInux.
You know, in our company we keep a wiki-page over which systems runs with 64-bit, and which with 32-bit. Because noone can remember, otherwise, and sometimes you need to know. As for how exposed this information is, that is a culture thing. Mac owners don't want to know, linux users do.
I find it totally laughable that you can sit there and criticize how Apple handled things when your only complains are theoretical. In reality, everything worked out quite well.
Resource wastage and security risks are real, but also something that is popular to ignore. I find it sad that you as a developer do not care about those things, but I suppose it is how it is these days.
That would be the "B" model, which includes a network card and 256Mb RAM, at app. $30.
Measure the temperatures and correlate it to the partial pressure of CO2 is one test.
A problem that Apple solved years ago in a far more elegant way.
No. The dependency problem was unsolved, and only a limited number of architectures. They build a mud hut and you claimed they solved the problem of building skyscrapers. Come on, this is simple facts!
Of course, OS X doesn't handle automatic dependency resolution at all, does it? It relies on bundling instead, wasting resources left and right, if I recall correctly.
Bundling is one of the best parts of OS X, IMO. Who the hell cares if it wastes a bit of disk space? It WORKS. And it is totally hassle free. No installers. No package managers. You just copy the app to your desktop.. and run. Don't want it anymore? Delete it. Want to test two versions of the same software (one beta, perhaps) side by side? Keep both copies. You dont' have to worry about an installer or package manager trying to overwrite the old version. THAT is what computers should be like. OS X handles dependency resolution by making it a non-issue. Disk space is cheap as hell. I'll take a polished, hassle free user experience with some wasted disk space any day.
Bundles means multiple copies of shared libraries. This has 2 implication: 1. the libraries cannot share memory pages and 2. security updates are not applied across the board, meaning that security updates are cumbersome to apply. So it might look like a good idea to someone who doesn't know much about the subject, but it is in fact a rather bad idea. (But if you like it, I have seen a few distribution on package managers on Linux that does this. Not popular, though, for good reasons.)
It is laughable that you can sit there and criticize how Apple handled it when Debian is only JUST NOW seriously addressing the general problem of managing multiple architectures.
Sigh. As I said, it is a problem Apple has never handled. Why should they? You cannot install Apple on many architectures. The solution they chose was an interim solution, and as such the solution was rather crude. The specific problem of coexisting 32 and 64 bit has been working in Debian for many, many years.
This thread is full of Linux users directly or indirectly complaining about how the transition to 64bit has been handled on LInux. Don't tell me it isn't a problem. I've dealt with it myself.
I must have been lucky, then. I never had a problem, excepting bugs in software.
In that argument, you are assuming that the probability of AGW being real or not is equal. We know better than that.
It is customary in the field to use 30-year periods. But you know, it's a null-hyptothesis thing: You set up a wanted confidence (say 1%) and then the null hypothesis (no link between CO2 and global mean temperature) and then run the numbers. I dare you to get to any other result than the scientific community, and publish the result ;)
Their loss because it could have made the current 32 to 64 bit transition a lot smoother had it been generally accepted and used. Think one kernel, at least 2 different architectures. Also, it would presumably extend down to the driver level too. You wouldn't even have to think about how many "bits" your system is. Everything would just work. The boot loader would pick the optimal arch and you'd be set. But I guess Linux users don't like things to be too easy. (I was a Linux user for many years, and this was actually the case in many ways).
Everything did just work --- bugs excepted. And do. The problem this is going to solve is "how to handle N architectures on the same installation, dependencies and all. Of course, OS X doesn't handle automatic dependency resolution at all, does it? It relies on bundling instead, wasting resources left and right, if I recall correctly.
While I am not an expert, it seems wasteful to me to load a bunch of architectures you won't ever need,
Define "load." It isn't l like you load all architectures into memory for all executables. They're just there if you need them. Also, I could be mistaken, but I believe the way OS X uses message passing, I don't think all shared libraries need to be multiarch. 32 bit programs can more smoothly interact with 64 bit programs/libraries.
You would be mistaken. Message passing in a architecture-independent way is expensive.
and wasteful to install a bunch of libraries for architectures you don't use. Typically, only a very small part of your installation will actually need to be multiarch. Of course, if I were *also* selling hardware, I might be a bit more wasteful :)
Oh please. Disk space is dirt cheap. That's just an excuse for laziness on the part of developers, packagers, and distribution maintainers.
Oh please. Laziness is just stuffing in everything, that's the banal, ham-fisted solution. That you think that you always have enough disk space shows how little you understand of the range of computer hardware Debian supports. E.g, I have a server that only have 16Gb of hard disk space, and needs most of that space for data. I appreciate not having space wasted because the Debian developers chose the ham-fisted approach.
Meanwhile, Linux users will continue to bitch and complain about things like Adobe Flash not working correctly due to architecture differences. Not properly handling multiarch has a a significant impact on user experience. Linux developers could learn from Apple. But instead, they insist on using Microsoft as the standard by which they measure themselves up to. And Microsoft has had their own 64bit transition problems. So sad.
Obviously, you did not understand what the issue was. Running a 32-bit browser in a 64-bit environment was what flashusers did, but it is suboptimal for a number of reasons.
Bottom line is that Apple managed to not only seamlessly transition from 32bit to 64bit, but also from PPC to x86. You have to give them credit.
lol
Typically, only a very small part of your installation will actually need to be multiarch.
Depends on how broadly you want to support 32 and 64 bit side by side. If you want to do it in the most transparent manner possible, you best make as much of the base system multiarch as possible. The problem with Linux is that there is no real "base" system. A Linux distribution is more or less one monolithic beast with every package tightly coupled with the next. It is kind all or nothing with Linux.
What are you talking about? Broadly support? Dependencies are (of course) resolved automatically. There is no "base system", no limit to the multi-arch support.
Anyway, I'm just saying that this "multiarch" support by Debian seems l
Both solutions are transparent for the user --- it is only something that matters to packagers. Debians solution is also transparent for the developer, though Apple's (I guess) is not, but then, Apple does not have packagers.
This idea (nicknamed "FAT elf") was considered and rejected across the board --- noone wanted it. While I am not an expert, it seems wasteful to me to load a bunch of architectures you won't ever need, and wasteful to install a bunch of libraries for architectures you don't use. Typically, only a very small part of your installation will actually need to be multiarch. Of course, if I were *also* selling hardware, I might be a bit more wasteful :)
In principle, you could run an emulator to run binaries for other architectures with e.g. qemu. I gather that that is not immediately in scope, though.
Looks to be some ARM with 128MB RAM, one USB and one HDMI + analog TV/audio.
You are probably not going to get many bitcoins using that machine.
Lots of theories are settled. To take something uncontroversial, Ohm's Laws are pretty settled. You won't find many any scientists trying to think up experiments to validate these laws. Of course, if someone actually managed to come up with an experiment that could repeatedly disprove the laws in some cases, something might happen --- but most likely, such an experiment would be flawed in some way.
In the same way, you won't find many scientist trying to validate that CO2 heats up the atmosphere by absorbing/reflecting infrared radiation.
All un-riddled now? :)
Apple chose to bundle all supported (2) architectures in all packages. While wasteful, it was effective given the low number of supported architectures (2). Given that debian support quite a few architectures, that route really isn't feasible. Is it more clear now?
Most of the scientists in climate are not studying the "if", because that question has been pretty much settled for, what, 40 years now? The questions they work on is "how much, how quickly, what distribution". Or at least, that's what I gather from reading the blogs of those scientists.
Should new data emerge that casts doubt on that "if", some will return to look at it. But one swallow doth not a summer make, and all that. This is one study against a mountain of others.
Such questions are better posed to bugzilla. See bug 204340, which will show you that this was fixed between 4.6 and 4.7.
Possibly, but I doubt it. Usually, you are using host names, and all the details are handled by (C or possibly Java) libraries, which means your old applications still works beautifully.
Of course, if you have intranet sites for registering your IP address or setting up a VPN or something like that, that might need an update. But the place where you write your business proposals, maintain your CRM database etc. should just work.
I just took the first one and googled. I didn't find any official announcements, but according to forum messages they plan to have IPv6 ready this year. So next year, maybe? ;)
I also suspect that since I have never heard of those companies, except GoDaddy, this is U.S-companies? The U.S. is possibly the country furthest behind in the IPv6-race, excepting Denmark (where I live).
Linode is slowly rolling out IPv6 finally :D
Anyway, today IPv6 is useful already to provide ssh-connectivity (and stuff that uses ssh like git) between developer machines. It's worth the setup cost just for that, in my estimation, even with tunnels.
It's a valid complain, but apparently not easy to fix. Why aren't website designs fluid, so that they scale to to the browser window? Mostly because support for the table-bit of CSS 2.1support is still broken in many modern browsers, I hear. Which makes it hard to get that holy-grail 2/3-column design-with-top-and-button that web designers love.
Try searching their bugzilla.. in this case, that would give you bug 204340, which is indeed fixed and should be part of 4.7.
How the heck could KDE4(.0) copy Vista?
As for your desktop woes, I think your problem is that you are using Desktop for the usecase Activities were designed to. If you instead of multiple desktop use multiple activities, you can have your wallpapers and your application configured per activity. As a bonus, you could even have some application on more than one (or all) activities, if that makes sense for you.
Yet other people report stellar performance on low-ends, so it's not clear-cut what is going on --- it could be a defective driver, some application going haywire on you, or a distro problem. I don't own a low-end computer (an Athlon64 is my current lowest-end), and on these KDE works just fine. The 1Gb RAM machine is struggling with the number of facebook tabs my wife wants to put on it, though.