Let's say you have a public table of voter-id -> vote. Each person can look up their own voter-id from a government controlled list to ensure privacy.
1. Person merges their vote entry into the data 2. At the very end of the voting period the table is stored on a public website, for easy bit by bit comparison by anyone. 3. Each person checks that their own entry exists and hasn't been modified. 4. Everyone can now count the votes and will get the same results, any discrepancies means the ballot box data has been altered.
This scheme has the following benefits:
* Your own vote can be verified to exist
* You can verify it hasn't been altered
* The amount of voters can be publicly verified
* Your vote is still secret from the public thanks to the government lookup-list.
If it needs to be hidden from the government too, there are various ways of accomplishing that as well such as:
* 3rd parties without government ties * An onion net of 3rd parties * possibly something using cryptographical hashes based on social-security numbers
Low-end phones are used by people who don't buy from app-stores anyway, so Linux is perfect, since it already has free mature software repos.
Maemo failed to be ready in time because they tried to reimplement everything and the kitchen sink, along with serious over-engineering issues. I bet people will be a lot more productive when resources are limited, and maybe dump some dev dead weight.
Linux is meeting very hard resistance from the whole apps/iphone/me-too/android crowd, because well, they just want a flashy phone with toys, not something that works. So, not focusing on this market (the market for morons) may be the best bet for getting a good working Linux phone, and a successor to Symbian when it comes to energy efficiency.
In the end, Linux will take over the whole mobile market, since nothing else has the same performance.
If I had any mod points, I'd mod you up. Maemo and later Meego, were/are the only truly open phone efforts that have gained any traction. Microsoft (probably in collusion with Apple and Google) is trying so very hard to kill Meego, but just like Linux, it'll be just about impossible for them to accomplish since it's already better in every single technical aspect.
FOSS is like a sleeping bear, slow, but when awoken, extremely hard to ignore.
I never bought an Android phone due to the lies Google made about the platform right from the start. It was supposed to be free (it never was) It was supposed to use Linux and therefore compatible (it uses it's java-slow-ass-walled-garden-reimplement-everything-approach)
Still using symbian due to the overwhelmingly better standby-time compared to all other competing OSes. Only a truly free Linux has any chance of competing with this (using power profiling, and a mature platform)
And that takes into account price breaks and volume pricing?
There exist 10 to 25 OEM packs of drives from many manufacturers, did you look at those mfg part no.s? What about a full pallet?
Only a moron would buy that amount of drives from a company that sells mainly to CONSUMERS. Even as a consumer, with large enough volumes, you may in some cases purchase straight from a distributor.
Yes, and this is why normal people don't like portage for stable systems.
As for being less optimal, I'd consider using untested versions of everything to be less optimal in general.
I don't think my point is coming across; if it's untested, there's no chance it would've even existed in any other model of package management. So it's a win-win situation, you get to choose whether to (simply) test it, or ignore it, since it's masked. It's no secret that Gentoo has the best documentation of any distro, and the highest rate of merging maintainer changes upstream. Clearly these guys know what they're doing. Learn from them instead of cussing what you don't understand.
So no git build at all, should ever even slightly break things?
Not on a stable branch. And in any case, it's not the package maintainers job to make sure some piece of software works. They can only assume it works in normal cases, but may need a tweak for that particular distro.
That is still 20X the time required for a full fedora dvd install.
Eh, that's only if you install from source, which Fedora cannot even do. With binaries it's the same time.
On our network we have things like: printserver ntpserver fontserver authserver intranet mail etc.
A very practical way of moving your laptop between home and work, and always automatically seeing all relevant printers. (just set your cups server to printserver:631)
We have always assumed that internet things end in a limited amount of TLDs. With this change that assumption goes out the window. I'm pretty sure this will lead to an immense amount of DNS filtering at all parties who didn't already implement it.
In protest, I'm going to filter out all TLDs ICANN creates from this day forth, on all networks I control, who's with me?
A good language should as often as possible make sloppy code crash or produce severely unexpected results. That's the beauty of C.
Less code is better than more code, and in the same spirit: No code is better than sloppy code.
The further C++ moves in the direction of languages designed for morons (java, C#, PHP), the further we get from our objective of having systems that actually work.
Let's start making the distinction between mission critical coders and all others. They can have their languages and we have ours in peace.
So a summary of your comments is still "it works for me" and therefore irrelevant, since your requirements are much lower.
Human testing is a good thing, if it doesn't stand in the way of, yes, you said it, human testing. it's unreasonable to expect someone to test the latest versions of 90k packages on all archs with all various build combinations. You can quickly see that the amount of combinations quickly goes up to the millions if not billions,
In the end, it's the job of the software author to make sure software works, and on all relevant archs, not the maintainer. A maintainers job is to qualify software to a distro, and (hopefully not) adjust something small to the peculiarities of that distro.
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.
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.
many of your complaints have nothing at all to do with what a package manager should do.
Apparently some people have way higher expectations of what a package manager should do. The "works for me" answer doesn't apply here since you clearly set the bar much lower.
You don't need crosscompilation made easy, fine. Don't need to move your hdd onto a different arch? Don't ever need to bootstrap systems? Don't need git or alternative repo format support? Some people do need these things,
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.
Good for you, me on the other hand, I've heard about people reinstalling ubuntu/red hat systems after an update gone wrong. 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. Try updating glibc/gcc and stuff like libpng to the latest version, and most often: you'll end up with multiple versions, you'll cook your system, or someone has already thought about this case and prepared a set of packages making the package repo 2x larger.
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.
eh? did you just say that you don't know how to crosscompile?
How is my freedom reduced? I can do whatever I damn well want with packages, or not. Again you are not making sense.
The packager chooses how packages are configured, compiled and linked, this obviously offers less freedom than a system where you can control these aspects.
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.
what is so bad about either? They do what they set out to do just fine.
They don't properly solve reverse-dependencies, not to talk about any kind of dependency graph that is more complicated than a tree. RPM even tries to do misguided things like transactions/rollback to solve other deficiencies that are there by design.
Neither supports source packages, which implies quite a lot of deficiencies by design: * Multiple arch support can never be any good, and requires insane amounts of maintainer effort. * 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) * No git/svn/hg/bzr support for packages. * The system you get through this process is very far from being optimal for your needs. ie. reduced freedom. * crosscompilation is a nightmare. * setting up a cross compiler makes the above sound like a pleasant dream. * bootstrapping one of these systems requires the knowledge located somewhere between 68k asm, black magic and voodoo.
If the choice was between them, I'd say neither, since they're about equally bad. But in this case the distro *already* uses.deb, so changing to an equally bad package format would be very stupid.
btw, I've rarely heard of a distro changing it's package manager, they might do it in th beginning, while experimenting, but once you have more than 90k packages in a repo...
It's meego without the shitty rpm packaging system Let people call their distros what ever they want and stop that handwaving.
Anyhow, these phones, are all mostly in the spirit of foss, which means you can recompile your kernel, change distros and customise it to the full extent of your wishes, just like any pc. That's why Maemo was a game-changer in the mobile industry, and why Microsoft are so afraid of it gaining traction.
If you're saving development time, performance isn't the only thing you're selling out. Most likely you're selling out one or all of the following: robustness, user-friendliness, memory usage, security, completeness.
I cannot agree. The silver bullet developers are looking for in order to save dev time just isn't there, no matter which language you pick.
If you write software carefully in C, C++ or java, you tend to end up with about the same amount of code and a similar amount of effort.
Threading, just like any new paradigm, is fundamentally harder code to write, no new invention is going to make it easier, unless you are hiding problems.
The problem is that the level of acceptance for buggy Java code is *way* lower than for C++ for example. People tend to ship broken products early. An (un/all)caught exception or one that doesn't produce a useful user message is still a crash, no matter how you look at it.
I pick C++ simply because it's tried, has more libs, better code and implementations going for it. And, as an added bonus, it isn't slow by design. Also, not all developers have the liberty of wasting memory such as a java environment mandates.
Process only creates problems, like someone auditing your code when not needed. Or noone auditing your code when you do need it. Same goes for testing, unimportant (old) parts get rigorously tested, but the latest development may be ignored entirely.
Process is something you need in a kindergarden, not when dealing with grown ups who are supposed to be trustworthy.
If hydrogen is to be compared to something, it should be compared to the (in-) efficiency of a car battery and generation of electricity. So far, everything is very experimental, but some optimistic predictions percieve the following:
* VHTR reactors produce hydrogen directly, which raises overall efficiency and safety. Note: Experiments have been dissapointing, but overall the development is moving in a good direction.
* Hydrogen is not pressurized while stored in a vehicle, instead it's bound to solids, such as metal hydrides. Reduced efficiency, but dangers are eliminated.
* People may use wind, water or sun power to top up their car hydrogen tanks.
* Hydrogen may be produced more efficiently than electricity from some of the less usual energy sources.
* Other added benefits are vehicles with much higher performance and/or engine simplicity, reducing the overall mass of the vehicle. Every reduction to the mass of a the vehicle is guaranteed green;)
With that being said, I think we can all agree that the following situations would be stupid:
* Producing hydrogen from fossil fuels
* Driving around with a high pressure hydrogen tank
The best coders I've known, people who actually solve problems by seeing the whole picture and making solutions work from end to end are all extroverts. It's also common for people who are extroverts to still incorrectly see themselves as introverts
Many of the introvert coders I've known, on the whole, are merely mediocre, supremely exceling in some tasks, but severely lacking in others.
Being extrovert enables you to aggressively push your ideas on a group, since in most cases decisions are taken casually, and are therefore probably bad decisions, and since the cost of change is high, it helps with technical people who can speak for themselves.
Also, specialisation hasn't conclusively been proven to be better than a more general skillset, the brain stagnates when it isn't learning enough, so being extrovert helps you to keep learning new things, simultaneously making you better at general and specialised work.
Working hard is not just about the time you put in, it's about what you create. Yes, americans are lazy, just like europe, very little new things are happening.
And at the current rate, if we don't do anything about it, we will be overrun.
You are talking about the inequalities between humans and corporations, while the protectionist agenda wants to increase those inequalities even further?
Protectionism is really just fancy name for pseudo-racism, and has no place in modern society.
BTW, your point about immigration taking months to process is only true in protectionist countries. In countries which are more free, it takes merely filling out a few forms, which rarely get scrutinised.
You're ignoring the problem, currently, a large part of networks are ipv4 and behind NAT. It's not likely to change for at least 5 years.
A blackbox experiment I did: * There's a NAT connection where I always get jitter with SIP. * IAX2 handles at least 20 lines with no jitter over the same connection. * If I use SIP over an SSH tunnel, the problem goes away.
You could say there's a flaw in the network config, but since *everything* else works well this indicates to me that there's a fundemental flaw in the design of SIP, possibly the flaw is that SIP uses multiple connections for a single call.
Depending on the type of NAT and the SIP implementation, it either works or it doesn't. Also I don't want to reconfigure my client each time I change network.
In my view, this is the *main* reason for the weak adoption of SIP, it's also getting way too complicated.
Slashdot Mirror
Let's say you have a public table of voter-id -> vote.
Each person can look up their own voter-id from a government controlled list to ensure privacy.
1. Person merges their vote entry into the data
2. At the very end of the voting period the table is stored on a public website, for easy bit by bit comparison by anyone.
3. Each person checks that their own entry exists and hasn't been modified.
4. Everyone can now count the votes and will get the same results, any discrepancies means the ballot box data has been altered.
This scheme has the following benefits:
* Your own vote can be verified to exist
* You can verify it hasn't been altered
* The amount of voters can be publicly verified
* Your vote is still secret from the public thanks to the government lookup-list.
If it needs to be hidden from the government too, there are various ways of accomplishing that as well such as:
* 3rd parties without government ties
* An onion net of 3rd parties
* possibly something using cryptographical hashes based on social-security numbers
Low-end phones are used by people who don't buy from app-stores anyway, so Linux is perfect, since it already has free mature software repos.
Maemo failed to be ready in time because they tried to reimplement everything and the kitchen sink, along with serious over-engineering issues.
I bet people will be a lot more productive when resources are limited, and maybe dump some dev dead weight.
Linux is meeting very hard resistance from the whole apps/iphone/me-too/android crowd, because well, they just want a flashy phone with toys, not something that works.
So, not focusing on this market (the market for morons) may be the best bet for getting a good working Linux phone, and a successor to Symbian when it comes to energy efficiency.
In the end, Linux will take over the whole mobile market, since nothing else has the same performance.
If I had any mod points, I'd mod you up.
Maemo and later Meego, were/are the only truly open phone efforts that have gained any traction.
Microsoft (probably in collusion with Apple and Google) is trying so very hard to kill Meego, but just like Linux, it'll be just about impossible for them to accomplish since it's already better in every single technical aspect.
FOSS is like a sleeping bear, slow, but when awoken, extremely hard to ignore.
I never bought an Android phone due to the lies Google made about the platform right from the start.
It was supposed to be free (it never was)
It was supposed to use Linux and therefore compatible (it uses it's java-slow-ass-walled-garden-reimplement-everything-approach)
Still using symbian due to the overwhelmingly better standby-time compared to all other competing OSes.
Only a truly free Linux has any chance of competing with this (using power profiling, and a mature platform)
Obviously they all invented ways of storing vast amounts of data in hair
And that takes into account price breaks and volume pricing?
There exist 10 to 25 OEM packs of drives from many manufacturers, did you look at those mfg part no.s?
What about a full pallet?
Only a moron would buy that amount of drives from a company that sells mainly to CONSUMERS.
Even as a consumer, with large enough volumes, you may in some cases purchase straight from a distributor.
I don't think my point is coming across; if it's untested, there's no chance it would've even existed in any other model of package management. So it's a win-win situation, you get to choose whether to (simply) test it, or ignore it, since it's masked.
It's no secret that Gentoo has the best documentation of any distro, and the highest rate of merging maintainer changes upstream. Clearly these guys know what they're doing. Learn from them instead of cussing what you don't understand.
Not on a stable branch. And in any case, it's not the package maintainers job to make sure some piece of software works. They can only assume it works in normal cases, but may need a tweak for that particular distro.
Eh, that's only if you install from source, which Fedora cannot even do. With binaries it's the same time.
On our network we have things like:
printserver
ntpserver
fontserver
authserver
intranet
mail
etc.
A very practical way of moving your laptop between home and work, and always automatically seeing all relevant printers. (just set your cups server to printserver:631)
We have always assumed that internet things end in a limited amount of TLDs. With this change that assumption goes out the window.
I'm pretty sure this will lead to an immense amount of DNS filtering at all parties who didn't already implement it.
In protest, I'm going to filter out all TLDs ICANN creates from this day forth, on all networks I control, who's with me?
A good language should as often as possible make sloppy code crash or produce severely unexpected results.
That's the beauty of C.
Less code is better than more code, and in the same spirit:
No code is better than sloppy code.
The further C++ moves in the direction of languages designed for morons (java, C#, PHP), the further we get from our objective of having systems that actually work.
Let's start making the distinction between mission critical coders and all others. They can have their languages and we have ours in peace.
So a summary of your comments is still "it works for me" and therefore irrelevant, since your requirements are much lower.
Human testing is a good thing, if it doesn't stand in the way of, yes, you said it, human testing.
it's unreasonable to expect someone to test the latest versions of 90k packages on all archs with all various build combinations.
You can quickly see that the amount of combinations quickly goes up to the millions if not billions,
In the end, it's the job of the software author to make sure software works, and on all relevant archs, not the maintainer.
A maintainers job is to qualify software to a distro, and (hopefully not) adjust something small to the peculiarities of that distro.
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.
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.
Apparently some people have way higher expectations of what a package manager should do.
The "works for me" answer doesn't apply here since you clearly set the bar much lower.
You don't need crosscompilation made easy, fine.
Don't need to move your hdd onto a different arch?
Don't ever need to bootstrap systems?
Don't need git or alternative repo format support?
Some people do need these things,
Good for you, me on the other hand, I've heard about people reinstalling ubuntu/red hat systems after an update gone wrong.
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.
Try updating glibc/gcc and stuff like libpng to the latest version, and most often: you'll end up with multiple versions, you'll cook your system, or someone has already thought about this case and prepared a set of packages making the package repo 2x larger.
eh? did you just say that you don't know how to crosscompile?
The packager chooses how packages are configured, compiled and linked, this obviously offers less freedom than a system where you can control these aspects.
Portage does, see crossdev.
They don't properly solve reverse-dependencies, not to talk about any kind of dependency graph that is more complicated than a tree.
RPM even tries to do misguided things like transactions/rollback to solve other deficiencies that are there by design.
Neither supports source packages, which implies quite a lot of deficiencies by design:
* Multiple arch support can never be any good, and requires insane amounts of maintainer effort.
* 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)
* No git/svn/hg/bzr support for packages.
* The system you get through this process is very far from being optimal for your needs. ie. reduced freedom.
* crosscompilation is a nightmare.
* setting up a cross compiler makes the above sound like a pleasant dream.
* bootstrapping one of these systems requires the knowledge located somewhere between 68k asm, black magic and voodoo.
If the choice was between them, I'd say neither, since they're about equally bad. .deb, so changing to an equally bad package format would be very stupid.
But in this case the distro *already* uses
btw, I've rarely heard of a distro changing it's package manager, they might do it in th beginning, while experimenting, but once you have more than 90k packages in a repo...
It's meego without the shitty rpm packaging system
Let people call their distros what ever they want and stop that handwaving.
Anyhow, these phones, are all mostly in the spirit of foss, which means you can recompile your kernel, change distros and customise it to the full extent of your wishes, just like any pc. That's why Maemo was a game-changer in the mobile industry, and why Microsoft are so afraid of it gaining traction.
If you're saving development time, performance isn't the only thing you're selling out. Most likely you're selling out one or all of the following: robustness, user-friendliness, memory usage, security, completeness.
I cannot agree.
The silver bullet developers are looking for in order to save dev time just isn't there, no matter which language you pick.
If you write software carefully in C, C++ or java, you tend to end up with about the same amount of code and a similar amount of effort.
Threading, just like any new paradigm, is fundamentally harder code to write, no new invention is going to make it easier, unless you are hiding problems.
The problem is that the level of acceptance for buggy Java code is *way* lower than for C++ for example. People tend to ship broken products early.
An (un/all)caught exception or one that doesn't produce a useful user message is still a crash, no matter how you look at it.
I pick C++ simply because it's tried, has more libs, better code and implementations going for it. And, as an added bonus, it isn't slow by design.
Also, not all developers have the liberty of wasting memory such as a java environment mandates.
I thought shields had to be dropped for phasers?
Developers can create solutions without process.
Process only creates problems, like someone auditing your code when not needed. Or noone auditing your code when you do need it. Same goes for testing, unimportant (old) parts get rigorously tested, but the latest development may be ignored entirely.
Process is something you need in a kindergarden, not when dealing with grown ups who are supposed to be trustworthy.
If hydrogen is to be compared to something, it should be compared to the (in-) efficiency of a car battery and generation of electricity. So far, everything is very experimental, but some optimistic predictions percieve the following:
* VHTR reactors produce hydrogen directly, which raises overall efficiency and safety.
Note: Experiments have been dissapointing, but overall the development is moving in a good direction.
* Hydrogen is not pressurized while stored in a vehicle, instead it's bound to solids, such as metal hydrides. Reduced efficiency, but dangers are eliminated.
* People may use wind, water or sun power to top up their car hydrogen tanks.
* Hydrogen may be produced more efficiently than electricity from some of the less usual energy sources.
* Other added benefits are vehicles with much higher performance and/or engine simplicity, reducing the overall mass of the vehicle. ;)
Every reduction to the mass of a the vehicle is guaranteed green
With that being said, I think we can all agree that the following situations would be stupid:
* Producing hydrogen from fossil fuels
* Driving around with a high pressure hydrogen tank
Talking from a purely technical point of view.
The best coders I've known, people who actually solve problems by seeing the whole picture and making solutions work from end to end are all extroverts.
It's also common for people who are extroverts to still incorrectly see themselves as introverts
Many of the introvert coders I've known, on the whole, are merely mediocre, supremely exceling in some tasks, but severely lacking in others.
Being extrovert enables you to aggressively push your ideas on a group, since in most cases decisions are taken casually, and are therefore probably bad decisions, and since the cost of change is high, it helps with technical people who can speak for themselves.
Also, specialisation hasn't conclusively been proven to be better than a more general skillset, the brain stagnates when it isn't learning enough, so being extrovert helps you to keep learning new things, simultaneously making you better at general and specialised work.
That's why they called it "OVI" (door in finnish)
It's easy to shut...
Working hard is not just about the time you put in, it's about what you create.
Yes, americans are lazy, just like europe, very little new things are happening.
And at the current rate, if we don't do anything about it, we will be overrun.
And what if they don't get infected by the same plague?
Maybe their culture somehow makes them immune?
Two wrongs doesn't make one right.
You are talking about the inequalities between humans and corporations, while the protectionist agenda wants to increase those inequalities even further?
Protectionism is really just fancy name for pseudo-racism, and has no place in modern society.
BTW, your point about immigration taking months to process is only true in protectionist countries. In countries which are more free, it takes merely filling out a few forms, which rarely get scrutinised.
You're ignoring the problem, currently, a large part of networks are ipv4 and behind NAT. It's not likely to change for at least 5 years.
A blackbox experiment I did:
* There's a NAT connection where I always get jitter with SIP.
* IAX2 handles at least 20 lines with no jitter over the same connection.
* If I use SIP over an SSH tunnel, the problem goes away.
You could say there's a flaw in the network config, but since *everything* else works well this indicates to me that there's a fundemental flaw in the design of SIP, possibly the flaw is that SIP uses multiple connections for a single call.
;)
Depending on the type of NAT and the SIP implementation, it either works or it doesn't.
Also I don't want to reconfigure my client each time I change network.
In my view, this is the *main* reason for the weak adoption of SIP, it's also getting way too complicated.