It sounds as if Git does rely on metadata in the foreign VCS!
The metadata you are talking about is stored in the local git repository that is importing the subversion one, not subversions. It does not affect upstreams repo at all. And again, git repos cloned from svn ones can interact just fine.
I have no issue with people doing whatever they like with metadata on their own local copies, only when it has effects on upsteam does it matter, which the changes to git you are proposing do
why should Git be changed to support Bazaar" (to which I said: it doesn't have to support Bazaar, it just has to support a single generic feature), and on the other hand, you're telling me "Bazaar should be changed for the sole specific purpose of supporting Git."
Not at all, I'm saying, if you want a good way to tell data is the same.. hash it. Certain designs have certain benefits, if you want the benefits git has, well, you have to go with a similar design. Don't want to change it? fine, then just don't get the features it yields either.
My logic is, what matters in a vcs, is the data. Having a uniquely identifiable and replicatable name based off that data is the only sensible thing in a distributed environment. Anyone who doesn't want to is fine, but has to put up with the problems they create by doing it their way.
Git doesn't store meta-data in svn repositories and yet two git repositories checked out from svn ones can interact just fine.
This all seems to be an artefact of bzr not addressing things by content and hash values like git does. Git's method avoids polluting the dataset of the original while still being interoperable between checked out aspects.
If anything it seems more a design flaw in bzr that should be remedied.
this works is because bzr-svn stores its own metadata in the Subversion properties (which means that another colleague who uses Bazaar can "bzr branch" the same Subversion repository and she'll see all of the Bazaar merge history). But I can't do this with Git.
So... should we put the metadata in for every single external client every other random person uses? Who cares if others using bzr can't see the bzr style merge history with the svn repo at all. I for one don't. The only thing I see happening is trying to mash together some superfluous system putting data that will never be used by the majority of cases and is not necessary into the repository.
When using other backends, it makes sense to work within what that backend can do, hacking things together with meta-data that it doesn't use seems... like a hack.
Brief listing of a couple things apple have done here.
To my knowledge the latest thing they tried was some funky crypto business that as of a year or so ago still hadn't been cracked. No use in buying from a company that is actively fighting against you using their product.
Do you really want 10 racks of servers with high-speed fans spinning away in your basement?
Yes, I have a 48u high rack right next to my bed. The noise becomes soothing after a while and it becomes very unnatural to not have it present when power goes out and the like.
I think it is very fitting, for companies who sue using patents to have said sued companies come back with even more patents and try to cause financial harm to them in the same manner.
There are too many people in the world for ideas to be the property of a single man. Companies still get first mover advantage if they are the first to do something.
We can fix a buggy os, we cannot fix a buggy firmware.
Besides that, flash is too varied for an OS to throw a one-size-fits-all at it. There are many different kinds of flash out there, and even different chips of the same kind can behave pretty differently.
With the myriad of different chipsets having similar but ever so slightly different functions that the linux kernel supports... you think supporting different types of flash will be completely beyond it? seriously?
For quite a while linux has been fine for any networking need that hasn't required over 40gbps over a single link. Added bonuses of consistent interface as other linux items, multiple hardware sources so you can find the cheapest bidder for what you need, and it scales to a point where only major internet backbones and telecom providers would typically require more.
To pick just one example, do you know of any CF cards which compress all data on the fly in order to increase effective flash lifespan by reducing the total amount of data written? (Since the SSD controllers in question use hardware compression engines which can handle hundreds of megabytes per second throughput, this also has the nice side effect of increasing effective performance, unless you're storing incompressible data.)
Remove the 'smart' controllers that kill things, the os can know far more information about the drive and the data being written to it. The only extra feature that makes sense is to keep a map of how many times each sector has been written to on the disk in the smart data, so the os can read it upon initially booting so you don't lose record of things when switching operating systems.
yum install qjackctl, run it, press start... it functions, just because it doesn't come stock with distros and a few distros packages aren't compiled to use it doesn't mean it couldn't easily be made to.
Lets me control multiple volume sources (I can hear skype ringing all over the house, but my music/movies doesn't leave the room)
You really think a multi-channel mixer is beyond jack? considering it caters to the needs of professionals too? really?
Lets me get hear sound from my virtual machines, and my server downstairs in the basement
I can do this with jack too, your point?
Doesn't even break the top five tasks on top for me. when playing audio and having my machine largely idle.
Likewise with jack.... your point?
Times have changed, mocking pulse makes no sense today. Jack and pulse have different design goals, get used to it.
Jack fits all of pulses uses except one, and that one is low power embedded where they want as little context switches as possible to enable low power states.
While I wholly agree pulseaudio is usable in modern times unlike when first adopted, the whole clusterfuck was unnecessary from the start.. and pulse still doesn't cater to uses jack does, while jack likes low latency too much for embedded, it is always a poor idea to sacrifice performance on every single machine for a tiny end case like low power embedded. (and yes, I even run jack on an original atom complete with synths etc without issue, and have done so recently on as old a machines as a pentium 2)
Hemingway in his later days was generally considered a conspiracy theorist, believing the fbi was tracking and bugging him everywhere.
It took 70 years for it to be discovered he was actually right.
While I'm sure there are exponentially more false claims of conspiracy than legitimate ones, people who sound paranoid can be completely right sometimes. When governments can successfully keep it secret until enough generations have passed for all involved to be dead, it demonstrates the capability of easily destroying peoples lives and credibility (at the very least for the duration of their life).
If I were to design and 3d print a fancy paperweight in blender, is this not computer aided design?
Will I really care about tolerances on it when said physical objects only purpose is to look nice and be heavy?
Wholeheartedly agree that blender is ill suited for cad, and you aren't exactly going to design engine parts with it even if you do use it to design things, but to be pedantic it would still be computer aided design so long as something physical with the general properties wished for is made.
Ubuntu does not maintains Long Term releases that long.
Ubuntu has not even existed for that long, I still remember its first release, primarily because even though I did not care for it they sent me a whole box of pressed cds to distribute amongst those likely to want to use it.
But more to the point, the packages from back in 2000 generally are still supported now, I mean take the linux kernel, if you have a bug with a certain piece of functionality or the like you can report it to the maintainer and it will generally be dealt with. It's the whole rolling release business in general. There is no reason not to run the latest as it is always incremental improvements, kind of like service packs for windows. Running old packages yields no support, but even with microsoft if you are running xp you were out of luck a long time ago if you want xp sp 0 supported.
in that case, go IBM MVS (it's free and legal to download too it's that old) the precursor to ibm z/os for it's mainframes. Worth it just for screwing with the marker. Most obscure thing I've ever used. From an era when human time was less expensive than cpu time... and it really shows.
it's unreasonable to expect someone to test the latest versions of 90k packages on all archs with all various build combinations.
Yes, and this is why normal people don't like portage for stable systems.
In the end, it's the job of the software author to make sure software works, and on all relevant archs, not the maintainer.
Package maintainers job is an integration and testing one for the distro he's packaging for. he makes binaries for the relevant archs and sets up dependencies etc. Before submission he _tests_ the build on the arch with relevant packages. While upstream do their best to make things work, they are still human and cannot take into account the sometimes slightly differing needs of different distros. The maintainer is the guy who tries to make it so that "works for us" is the case of everyone on that distribution for that package.
Any sane developer will have made their software with endianness (and arch specific optimisations) in mind. If not, that piece of software deserves to be marked 100% broken.
So no git build at all, should ever even slightly break things? accidents happen, even otherwise well designed software has bugs introduced at times. Even if the bug is accidentally breaking a strange architecture that said developer is not even using.
The package maintainer _tests_ the build on all archs, and if some new bug appears that is as yet unresolved, either fixes and sends patches upstream, or just reverts the version available.
On a modern system (intel quad) it takes less than one day to rebuild everything from scratch, that's about 2000 packages including gnome, kde 3.5 and 4.
It's about choice, and you can have both binary and source packages mixed without a problem, if you don't mind a less optimal system.
That is still 20X the time required for a full fedora dvd install. As for being less optimal, I'd consider using untested versions of everything to be less optimal in general.
Don't need to move your hdd onto a different arch?
If I do it will still be able to access the data, if you are speaking of the os drive I will simply install the appropriate arch distro. How is this an issue?
Don't ever need to bootstrap systems?
right here I presently have x86, ppc, 68k, SH, mips and arm linux systems. I have no problems booting all of them. What is your problem with it?
Don't need git or alternative repo format support?
No, because the packager checks out a version, builds it and then _tests_ the build
What you are talking about amounts to automatically building from latest git commits, which is a recipe for disaster for inexperienced users, and even experienced users have to be careful.
Some people do need these things,
I do everything you have said, but without portage. Funnily enough, most other developers do too, without issue.
Good for you, me on the other hand, I've heard about people reinstalling ubuntu/red hat systems after an update gone wrong.
I've not reinstalled a fedora system since fedora 3, and am on the latest at present. I've heard stories of people as root going rm -rf / before too, doesn't mean it's a problem with anything to do with the os.
You ignored what I said about deps, clearly some distros try to keep their package topology very simple, since the package manager cannot resolve more complicated dep graphs.
It is the way it is because package maintainers _test_ each package with everything else first. Letting everyone compile random versions of everything can result in chaos and lack of testing if the result actually works, especially if you are using a latest git commit as the base of your packages.
Speaking of portage though, my primary developer system is not the greatest but not too shabby, quad core, 12gb of ram, but even with this setup the sheer number of pieces of software I use would result in _weeks_ of compile time. This is _not_ acceptable. If I don't update for a while I can wind up with up to 3gb of binary updates. I do not like the idea of periodically heavily loading my machine for a week just to update to the latest items. Neither should you. Systems are there to _use_.
eh? did you just say that you don't know how to crosscompile?
No, I said some software packages don't like being cross compiled due to endian and 32/64bit specific items, or reliance on libraries that have said same problems. Automating compilation of such items without testing is absolute chaos unless you limit it to items that are _known_ good, and if you are doing that why not simply let the package maintainer compile and test for you?
Overall you've drank too much portage cool-aid, the jobs you are proposing a package manager be in charge of goes strongly against the linux philosophy of modular pieces that do single things well. You are talking about trying to get a package manager to do everything a maintainer does, this can work but is dangerous when things aren't tested, human testing of packages is a _good_ thing.
People type 'yum install' or 'apt-get' then the name of their program, and it resolves all dependencies and gets said program, I have not had a repository dependency problem in the last decade.
* Multiple arch support can never be any good, and requires insane amounts of maintainer effort.
I don't know about you, but I wouldn't mind maintainers actually.. you know... testing.. their _built_ packages to work on x system. Source packages are of no use to you in cross compiling you make the program useless through bugs, or worse yet the damn thing doesn't compile at all.
Dynamic linking is flaky at best. (stable ABI is a package maintainers dream, not a reality,it is a goal not shared by the actual developers of said packaged software)
I don't know what you are on about here, all my packaged software uses shared libraries just fine and dandy. Everything would be a shite sight bigger if we weren't using dynamic linking you know.
* No git/svn/hg/bzr support for packages.
That just plain does not make sense. The source code repository is one of those things that the package has no use for. I fail to see the need or what possible purpose it would have. to somehow integrate git into your package manager.
* The system you get through this process is very far from being optimal for your needs. ie. reduced freedom.
How is my freedom reduced? I can do whatever I damn well want with packages, or not. Again you are not making sense.
* crosscompilation is a nightmare.
I've done cross compilation before, it was rather painless so long as the code wasn't endian or 32/64bit specific.
* setting up a cross compiler makes the above sound like a pleasant dream.
I've baked my own compiler for superhitachi for an embedded project I was playing with some years ago, aside from the crazy compile time it wasn't too bad. Agree it isn't for newbies though but if you are baking your own compilers for strange archs you shouldn't be a newbie anyway. No package manager will fix this, it is not the job of the package manager to fix this.
* bootstrapping one of these systems requires the knowledge located somewhere between 68k asm, black magic and voodoo.
Why the devil does the package manager make it harder to boot? it just manager packages, so long as whatever binaries you need etc and boot loaders are there you do not have a problem. Booting is not part of the package manager.
Overall I think you should research things a bit more, many of your complaints have nothing at all to do with what a package manager should do. Package managers manage packages, not check out source code from a git repo and other such random things. Packages themselves are just files with lots of related metadata with dependencies etc.
having 20 $1 bills is generally more convenient than having just 4 $5's... if it were not so, then the $5 would have had the same reason to be replaced with a coin as the $1 bill did, owing to its use and we wouldn't have the $5 bill today either.
four $5 notes are more useful than 20 $1 notes. people (at least around here) do not carry 20 $1 notes because it is inconvenient both to carry and count. The same goes with carrying 20 $1 coins, people only carry a few coins on them, it is useful for these coins to actually be worth something.
Having notes of larger denomination is useful, you keep a few small notes for potential smaller purchases, and larger ones for the remainder of the money.
You wouldn't carry $10,000 in one dollar notes would you?
You mean that food does not have an inherent value? Or shelter? Or medicine?
Not at all, you've assigned it value, although it is a generally common value of humans based on their biological urges of wanting to live (since those that don't tend to well.. die). Those items themselves have no inherent value, it is solely your own view.
Value is a result of supply and demand. If there is a limited supply of something that people want, then it has value. The more people demand it, or the more the supply is limited, the more value it has. People don't just "assign" value to something by some magical process.
People have already assigned it value, not because of supply and demand, but because they _want_ it. They consider it valuable enough to want to acquire, so it has some value to them, otherwise why would they try to get it?
In the cases of currencies, most people already agree there is no inherent value. But what they fail to realize is that even general purpose items have no inherent value either, people value the currencies for their ability to acquire other items/services which they do value. The value if those items is also artbitrary, To a devout hindu person that was starving a pound of steak would have no value in aiding their hunger.
To an anti-firearm person a brand new walther ppk is worthless to them (except for perhaps selling it and trading its value for something else, but the point is even though it has utility it has no inherent value... all of the values were assigned by people).
Compare this with the demand for those other currencies, which is the result of the need to pay taxes, the ability to have a court settle a dispute over a debt, and so forth. Nothing magical about it; the demand for currency is a result of the legal framework that surrounds it, and the supply comes from governments and banking systems.
The original demand for currency was to find something of which everyone could agree to value for the sake of exchanging other items that they or the people they were bartering to valued. The only reason people assign value to currency are the other things of perceived value they can get with them.
When I can take you to court for defaulting on a Bitcoin loan, or when I can pay my taxes in Bitcoins, there will be no question about whether or not Bitcoins have any actual value.
I can purchase services that I value right now with bitcoin, so why should i not value bitcoin because of the subjective value I have for those services that it can acquire for me?
Likewise if some eccentric math head decided to start personally valuing bitcoins for some crazy bizarre reason, how is that not value even though they are not even purchasing anything with them?
What people value is quite arbitrary, aside from biological urges most people have but even then that does not mean items have _inherent_ value, only that many people value it.
It's up to the proponents of bitcoin to convince the rest of the public that your currency has value. Until you can do that, it IS worthless.
Not everyone needs to use bitcoin, so long as people that you wish to trade with value it, then how is it not valuable?
I could trade bitcoins for services i may require right now whereby bitcoin would be a far more convenient method of transfer of the funds. When multiple people you are interested in trading with all value it, how is it then of no value to you when you can acquire services you may need with it?
Slashdot Mirror
It sounds as if Git does rely on metadata in the foreign VCS!
The metadata you are talking about is stored in the local git repository that is importing the subversion one, not subversions. It does not affect upstreams repo at all. And again, git repos cloned from svn ones can interact just fine.
I have no issue with people doing whatever they like with metadata on their own local copies, only when it has effects on upsteam does it matter, which the changes to git you are proposing do
why should Git be changed to support Bazaar" (to which I said: it doesn't have to support Bazaar, it just has to support a single generic feature), and on the other hand, you're telling me "Bazaar should be changed for the sole specific purpose of supporting Git."
Not at all, I'm saying, if you want a good way to tell data is the same.. hash it. Certain designs have certain benefits, if you want the benefits git has, well, you have to go with a similar design. Don't want to change it? fine, then just don't get the features it yields either.
My logic is, what matters in a vcs, is the data. Having a uniquely identifiable and replicatable name based off that data is the only sensible thing in a distributed environment. Anyone who doesn't want to is fine, but has to put up with the problems they create by doing it their way.
Git doesn't store meta-data in svn repositories and yet two git repositories checked out from svn ones can interact just fine.
This all seems to be an artefact of bzr not addressing things by content and hash values like git does. Git's method avoids polluting the dataset of the original while still being interoperable between checked out aspects.
If anything it seems more a design flaw in bzr that should be remedied.
this works is because bzr-svn stores its own metadata in the Subversion properties (which means that another colleague who uses Bazaar can "bzr branch" the same Subversion repository and she'll see all of the Bazaar merge history). But I can't do this with Git.
So... should we put the metadata in for every single external client every other random person uses? Who cares if others using bzr can't see the bzr style merge history with the svn repo at all. I for one don't. The only thing I see happening is trying to mash together some superfluous system putting data that will never be used by the majority of cases and is not necessary into the repository.
When using other backends, it makes sense to work within what that backend can do, hacking things together with meta-data that it doesn't use seems... like a hack.
Brief listing of a couple things apple have done here.
To my knowledge the latest thing they tried was some funky crypto business that as of a year or so ago still hadn't been cracked. No use in buying from a company that is actively fighting against you using their product.
Do you really want 10 racks of servers with high-speed fans spinning away in your basement?
Yes, I have a 48u high rack right next to my bed. The noise becomes soothing after a while and it becomes very unnatural to not have it present when power goes out and the like.
I think it is very fitting, for companies who sue using patents to have said sued companies come back with even more patents and try to cause financial harm to them in the same manner.
There are too many people in the world for ideas to be the property of a single man. Companies still get first mover advantage if they are the first to do something.
We can fix a buggy os, we cannot fix a buggy firmware.
Besides that, flash is too varied for an OS to throw a one-size-fits-all at it. There are many different kinds of flash out there, and even different chips of the same kind can behave pretty differently.
With the myriad of different chipsets having similar but ever so slightly different functions that the linux kernel supports... you think supporting different types of flash will be completely beyond it? seriously?
How about a linux based solution?
For quite a while linux has been fine for any networking need that hasn't required over 40gbps over a single link. Added bonuses of consistent interface as other linux items, multiple hardware sources so you can find the cheapest bidder for what you need, and it scales to a point where only major internet backbones and telecom providers would typically require more.
This.
To pick just one example, do you know of any CF cards which compress all data on the fly in order to increase effective flash lifespan by reducing the total amount of data written? (Since the SSD controllers in question use hardware compression engines which can handle hundreds of megabytes per second throughput, this also has the nice side effect of increasing effective performance, unless you're storing incompressible data.)
This should be the job of the os, not some buggy controller that can screw it up horrendously.
Remove the 'smart' controllers that kill things, the os can know far more information about the drive and the data being written to it. The only extra feature that makes sense is to keep a map of how many times each sector has been written to on the disk in the smart data, so the os can read it upon initially booting so you don't lose record of things when switching operating systems.
Just works (jack DOES NOT just work)
yum install qjackctl, run it, press start... it functions, just because it doesn't come stock with distros and a few distros packages aren't compiled to use it doesn't mean it couldn't easily be made to.
Lets me control multiple volume sources (I can hear skype ringing all over the house, but my music/movies doesn't leave the room)
You really think a multi-channel mixer is beyond jack? considering it caters to the needs of professionals too? really?
Lets me get hear sound from my virtual machines, and my server downstairs in the basement
I can do this with jack too, your point?
Doesn't even break the top five tasks on top for me. when playing audio and having my machine largely idle.
Likewise with jack.... your point?
Times have changed, mocking pulse makes no sense today. Jack and pulse have different design goals, get used to it.
Jack fits all of pulses uses except one, and that one is low power embedded where they want as little context switches as possible to enable low power states.
While I wholly agree pulseaudio is usable in modern times unlike when first adopted, the whole clusterfuck was unnecessary from the start.. and pulse still doesn't cater to uses jack does, while jack likes low latency too much for embedded, it is always a poor idea to sacrifice performance on every single machine for a tiny end case like low power embedded. (and yes, I even run jack on an original atom complete with synths etc without issue, and have done so recently on as old a machines as a pentium 2)
Hemingway in his later days was generally considered a conspiracy theorist, believing the fbi was tracking and bugging him everywhere.
It took 70 years for it to be discovered he was actually right.
While I'm sure there are exponentially more false claims of conspiracy than legitimate ones, people who sound paranoid can be completely right sometimes. When governments can successfully keep it secret until enough generations have passed for all involved to be dead, it demonstrates the capability of easily destroying peoples lives and credibility (at the very least for the duration of their life).
Pulseaudio sound latency is still shit, it cannot compare to the likes of jack.
If I were to design and 3d print a fancy paperweight in blender, is this not computer aided design?
Will I really care about tolerances on it when said physical objects only purpose is to look nice and be heavy?
Wholeheartedly agree that blender is ill suited for cad, and you aren't exactly going to design engine parts with it even if you do use it to design things, but to be pedantic it would still be computer aided design so long as something physical with the general properties wished for is made.
Ubuntu does not maintains Long Term releases that long.
Ubuntu has not even existed for that long, I still remember its first release, primarily because even though I did not care for it they sent me a whole box of pressed cds to distribute amongst those likely to want to use it.
But more to the point, the packages from back in 2000 generally are still supported now, I mean take the linux kernel, if you have a bug with a certain piece of functionality or the like you can report it to the maintainer and it will generally be dealt with. It's the whole rolling release business in general. There is no reason not to run the latest as it is always incremental improvements, kind of like service packs for windows. Running old packages yields no support, but even with microsoft if you are running xp you were out of luck a long time ago if you want xp sp 0 supported.
in that case, go IBM MVS (it's free and legal to download too it's that old) the precursor to ibm z/os for it's mainframes. Worth it just for screwing with the marker. Most obscure thing I've ever used. From an era when human time was less expensive than cpu time... and it really shows.
it's unreasonable to expect someone to test the latest versions of 90k packages on all archs with all various build combinations.
Yes, and this is why normal people don't like portage for stable systems.
In the end, it's the job of the software author to make sure software works, and on all relevant archs, not the maintainer.
Package maintainers job is an integration and testing one for the distro he's packaging for. he makes binaries for the relevant archs and sets up dependencies etc. Before submission he _tests_ the build on the arch with relevant packages. While upstream do their best to make things work, they are still human and cannot take into account the sometimes slightly differing needs of different distros. The maintainer is the guy who tries to make it so that "works for us" is the case of everyone on that distribution for that package.
Any sane developer will have made their software with endianness (and arch specific optimisations) in mind. If not, that piece of software deserves to be marked 100% broken.
So no git build at all, should ever even slightly break things? accidents happen, even otherwise well designed software has bugs introduced at times. Even if the bug is accidentally breaking a strange architecture that said developer is not even using.
The package maintainer _tests_ the build on all archs, and if some new bug appears that is as yet unresolved, either fixes and sends patches upstream, or just reverts the version available.
On a modern system (intel quad) it takes less than one day to rebuild everything from scratch, that's about 2000 packages including gnome, kde 3.5 and 4. It's about choice, and you can have both binary and source packages mixed without a problem, if you don't mind a less optimal system.
That is still 20X the time required for a full fedora dvd install. As for being less optimal, I'd consider using untested versions of everything to be less optimal in general.
You don't need crosscompilation made easy, fine.
It is already easy.
Don't need to move your hdd onto a different arch?
If I do it will still be able to access the data, if you are speaking of the os drive I will simply install the appropriate arch distro. How is this an issue?
Don't ever need to bootstrap systems?
right here I presently have x86, ppc, 68k, SH, mips and arm linux systems. I have no problems booting all of them. What is your problem with it?
Don't need git or alternative repo format support?
No, because the packager checks out a version, builds it and then _tests_ the build
What you are talking about amounts to automatically building from latest git commits, which is a recipe for disaster for inexperienced users, and even experienced users have to be careful.
Some people do need these things,
I do everything you have said, but without portage. Funnily enough, most other developers do too, without issue.
Good for you, me on the other hand, I've heard about people reinstalling ubuntu/red hat systems after an update gone wrong.
I've not reinstalled a fedora system since fedora 3, and am on the latest at present. I've heard stories of people as root going rm -rf / before too, doesn't mean it's a problem with anything to do with the os.
You ignored what I said about deps, clearly some distros try to keep their package topology very simple, since the package manager cannot resolve more complicated dep graphs.
It is the way it is because package maintainers _test_ each package with everything else first. Letting everyone compile random versions of everything can result in chaos and lack of testing if the result actually works, especially if you are using a latest git commit as the base of your packages.
Speaking of portage though, my primary developer system is not the greatest but not too shabby, quad core, 12gb of ram, but even with this setup the sheer number of pieces of software I use would result in _weeks_ of compile time. This is _not_ acceptable. If I don't update for a while I can wind up with up to 3gb of binary updates. I do not like the idea of periodically heavily loading my machine for a week just to update to the latest items. Neither should you. Systems are there to _use_.
eh? did you just say that you don't know how to crosscompile?
No, I said some software packages don't like being cross compiled due to endian and 32/64bit specific items, or reliance on libraries that have said same problems. Automating compilation of such items without testing is absolute chaos unless you limit it to items that are _known_ good, and if you are doing that why not simply let the package maintainer compile and test for you?
Overall you've drank too much portage cool-aid, the jobs you are proposing a package manager be in charge of goes strongly against the linux philosophy of modular pieces that do single things well. You are talking about trying to get a package manager to do everything a maintainer does, this can work but is dangerous when things aren't tested, human testing of packages is a _good_ thing.
They don't properly solve reverse-dependencies
People type 'yum install' or 'apt-get' then the name of their program, and it resolves all dependencies and gets said program, I have not had a repository dependency problem in the last decade.
* Multiple arch support can never be any good, and requires insane amounts of maintainer effort.
I don't know about you, but I wouldn't mind maintainers actually.. you know... testing.. their _built_ packages to work on x system. Source packages are of no use to you in cross compiling you make the program useless through bugs, or worse yet the damn thing doesn't compile at all.
Dynamic linking is flaky at best. (stable ABI is a package maintainers dream, not a reality,it is a goal not shared by the actual developers of said packaged software)
I don't know what you are on about here, all my packaged software uses shared libraries just fine and dandy. Everything would be a shite sight bigger if we weren't using dynamic linking you know.
* No git/svn/hg/bzr support for packages.
That just plain does not make sense. The source code repository is one of those things that the package has no use for. I fail to see the need or what possible purpose it would have. to somehow integrate git into your package manager.
* The system you get through this process is very far from being optimal for your needs. ie. reduced freedom.
How is my freedom reduced? I can do whatever I damn well want with packages, or not. Again you are not making sense.
* crosscompilation is a nightmare.
I've done cross compilation before, it was rather painless so long as the code wasn't endian or 32/64bit specific.
* setting up a cross compiler makes the above sound like a pleasant dream.
I've baked my own compiler for superhitachi for an embedded project I was playing with some years ago, aside from the crazy compile time it wasn't too bad. Agree it isn't for newbies though but if you are baking your own compilers for strange archs you shouldn't be a newbie anyway. No package manager will fix this, it is not the job of the package manager to fix this.
* bootstrapping one of these systems requires the knowledge located somewhere between 68k asm, black magic and voodoo.
Why the devil does the package manager make it harder to boot? it just manager packages, so long as whatever binaries you need etc and boot loaders are there you do not have a problem. Booting is not part of the package manager.
Overall I think you should research things a bit more, many of your complaints have nothing at all to do with what a package manager should do. Package managers manage packages, not check out source code from a git repo and other such random things. Packages themselves are just files with lots of related metadata with dependencies etc.
If the choice was between them, I'd say neither, since they're about equally bad.
what is so bad about either? They do what they set out to do just fine.
having 20 $1 bills is generally more convenient than having just 4 $5's... if it were not so, then the $5 would have had the same reason to be replaced with a coin as the $1 bill did, owing to its use and we wouldn't have the $5 bill today either.
four $5 notes are more useful than 20 $1 notes. people (at least around here) do not carry 20 $1 notes because it is inconvenient both to carry and count. The same goes with carrying 20 $1 coins, people only carry a few coins on them, it is useful for these coins to actually be worth something.
Having notes of larger denomination is useful, you keep a few small notes for potential smaller purchases, and larger ones for the remainder of the money.
You wouldn't carry $10,000 in one dollar notes would you?
It's meego without the shitty rpm packaging system
how is rpm worse than .deb?
and yes I use both daily.
Global coal, oil, gas and uranium stocks are predicted to run out in the next few hundred years.
Rest of it is half plausible, but running out of uranium in the next few hundred years? using fast breeder reactors? not likely.
It is still finite of course, but it will last a shite sight longer than all the other things you mentioned by almost an order of magnitude.
You mean that food does not have an inherent value? Or shelter? Or medicine?
Not at all, you've assigned it value, although it is a generally common value of humans based on their biological urges of wanting to live (since those that don't tend to well.. die). Those items themselves have no inherent value, it is solely your own view.
Value is a result of supply and demand. If there is a limited supply of something that people want, then it has value. The more people demand it, or the more the supply is limited, the more value it has. People don't just "assign" value to something by some magical process.
People have already assigned it value, not because of supply and demand, but because they _want_ it. They consider it valuable enough to want to acquire, so it has some value to them, otherwise why would they try to get it?
In the cases of currencies, most people already agree there is no inherent value. But what they fail to realize is that even general purpose items have no inherent value either, people value the currencies for their ability to acquire other items/services which they do value. The value if those items is also artbitrary, To a devout hindu person that was starving a pound of steak would have no value in aiding their hunger.
To an anti-firearm person a brand new walther ppk is worthless to them (except for perhaps selling it and trading its value for something else, but the point is even though it has utility it has no inherent value... all of the values were assigned by people).
Compare this with the demand for those other currencies, which is the result of the need to pay taxes, the ability to have a court settle a dispute over a debt, and so forth. Nothing magical about it; the demand for currency is a result of the legal framework that surrounds it, and the supply comes from governments and banking systems.
The original demand for currency was to find something of which everyone could agree to value for the sake of exchanging other items that they or the people they were bartering to valued. The only reason people assign value to currency are the other things of perceived value they can get with them.
When I can take you to court for defaulting on a Bitcoin loan, or when I can pay my taxes in Bitcoins, there will be no question about whether or not Bitcoins have any actual value.
I can purchase services that I value right now with bitcoin, so why should i not value bitcoin because of the subjective value I have for those services that it can acquire for me?
Likewise if some eccentric math head decided to start personally valuing bitcoins for some crazy bizarre reason, how is that not value even though they are not even purchasing anything with them?
What people value is quite arbitrary, aside from biological urges most people have but even then that does not mean items have _inherent_ value, only that many people value it.
It's up to the proponents of bitcoin to convince the rest of the public that your currency has value. Until you can do that, it IS worthless.
Not everyone needs to use bitcoin, so long as people that you wish to trade with value it, then how is it not valuable?
I could trade bitcoins for services i may require right now whereby bitcoin would be a far more convenient method of transfer of the funds. When multiple people you are interested in trading with all value it, how is it then of no value to you when you can acquire services you may need with it?