I look for places to use my math skills, and find plenty. I was differentiating to find minimums this morning, and I've used a lot of calculus, linear algebra, and even number theory recently. However, I could find plenty of work which requires nothing more than knowledge of how to use a 4-function calculator. I just don't personally find such work very satisfying.
I've been instrumental in hiring decisions of couple of dozen programmers by now. If a person says math isn't their thing, it's not the end of the interview, though strong math skills are a plus. I'll often be interested in a physics Ph. D. or mathematician, even if they don't yet know how to code, but if a guy can't show strong analytic skills in math, I need to see some demonstration of coding skills. For example, a person with strong 3-D visualization skills can become a good router guy without advanced math skills, though they have to be competent in high school level math. We just put such people on projects that wont require advanced math.
In our work (chip design related algorithms), we have to have some serious math geeks, but it doesn't have to be the whole team. We've got a brilliant IIT grad who did our sparse matrix backwards Trapezoid interconnect delay simulator, running 1000X faster than SPICE, with the same accuracy. There's some cool discrete math in our logic optimizer. The linear algebra in the placer is cool. We're also doing some analog design aids, and it really helps if you understand the math behind the algorithms you're expected to code, and analog optimization is heavily mathematical. Advanced logic optimization some advanced math, as does many algorithms that come up in chip design. I've been doing a bit of analog, which is heavy into Z transforms, and Laplace transforms. I've also recently done a bit of signal processing involving custom optimized FFT code. Transformer design can be done by "rule of thumb", but to write the code to do it well requires solid understanding of both the physics and the math behind it. Those who enjoy advanced math appreciate being assigned projects where they can put their mathematical reasoning skills to good use, and those who hate math appreciate not being on those projects. It all works out. You just need a good mix.
I suspect you are right. The growth curve for solar beats all the other alternatives, and if it keeps on this path, we'll all have cheap solar energy in a decade or two. However, I think we need to invest in the whole spectrum of alternatives. Molten salt reactors, for example, show some promise of lowering costs while dramatically improving safety and offering a solution to the waste disposal problem. It might be pie in the sky, but I'd fund research with my tax dollars.
You are 100% correct. The dorks who don't know that solar is cost effective in certain markets simply haven't researched it. However, most of us don't live in southern California deserts. Contributing factors there include federal and state subsidies, and insanely high regular electric rates, as well as reliable, intense sunlight, which provides power when you need it most: during peak demand. Edison has been running solar farms profitably in southern California for decades.
TFA is factually correct. We could generate all the power we need from solar. Run high voltage across the country, and we could provide power to New York from New Mexico. It's just tech pioneered by Brazil in the '70s.
However, no one is saying that solar is currently the cheapest solution for power, or even the cheapest renewable energy. It may get there, but it's not yet. We could power the country on solar. We could do it with wind. We could do it with geothermal, or gen IV nuclear. I think we need to invest in them all, and let the best technology win. Unfortunately, the reality is we'll continue polluting the planet until even stupid people realize it's a bad idea.
It sounds somewhat similar to Debian and Ubuntu that way. You definitely work your way up. I was a long time RedHat and then a Fedora fan. RedHat's doing well and making money from open source, so I consider them a huge success story. On the other hand, they are strongly invested in keeping business as usual. They are the number 1 solution for business Linux needs. As such, they're the platform that gets the most testing from commercial Linux software vendors. The (unfortunately major) changes I'm talking about would enable software vendors to run on all the Linux distros, eliminating a major market barrier, and likely cutting into RedHat profits. Just about any distro would be more stable, and new features added to one distro could easily be installed to another, again reducing market barriers. I admire the RedHat guys, but I think leveling the playing field in Linux would be against their best interest.
Sure, redesign. Why not build it on top of the existing package managers?
Unless you have unusual needs, you will find life just fine with the existing packaging managers. Porn, BitTorrent downloads, music, you name it. It's all there for a horny 20-year-old.
I'm not blind, and never will be, which makes me somewhat hesitant to complain. I'm simply suffering from central vision loss, which is very much preferable to real blindness. Now, if you were losing sight, and had to depend on future Linux distros to make their shit accessible, you'd be all good about that, right? Because every single system out there is so accessible to the blind! I'll mention Gnewsense, just because you might have heard of them. They would love to support people with vision disorders, but they can't. It's not their fault. RMS is all for Gnewsense, and all for accessibility, but it doesn't fucking work!
The reason it does not work is the stupidity in our current packaging managers.
Actually, I live in Chapel Hill, NC, quite close to RedHat HQ. I've never met anyone in person who works for RedHat. If you know someone I should talk to, I'm just crazy enough to call/e-mail them. Not that I'm looking for a new job... I have significant responsibilities in helping my current one succeed. However, I'd be interested in meeting people living near me who are as you describe.
I've had even a bit more wine, so this idea is even dumber, but here's the brain fart... guys like you who get it, probably because of real experience as a developer, could form a new e-mail group. I suspect there are enough of us out there to make a difference for GNU/Linux.
I just had a stupid somewhat wine-induced brain-fart. What if those of us with substantial experience developing code for Linux who fear for it's future somehow got together on an e-mail group free of the pesky hoards of newbies without a clue? If we could filter out the "everything is perfect, just the way it is" crowd, we might be able to build a community capable of saving GNU/Linux. Note I say GNU/Linux, because Linux on it's own has a bright future without us.
The problem with Linux is guys with a clue like you don't get moderated up on slashdot. For every author of several books on Linux, there are 1,000 newbie Linux fanatics with mod points who don't appreciate your lack of vision.
I think I'm noticing a dividing line between the die-hard "it's perfect the way it is" crowd and those who seem to think distributing software in Linux could be improved: I'm guessing you write software, rather than package software for your particular favorite distro. It's authors who are getting screwed.
OK, I haven't run Cadence on many machines, so I believe you are correct. The Mentor binaries, OTOH, link in just about everything, including their own Java libraries. The benefit is it just works, pretty much everywhere.
So... you installed Ubuntu 12.04, and downgraded to Gnome 2.0 with a simple apt command with no problems? The mechanism to make all this work exists. All it requires is for every author of every package to do extra work for every distro and get it right. No problem, right? And, of course, even if you get it to install OK, you'll be running combinations of.so libraries that no author has ever tested. Good luck with that.
Glad to see your showing some flexibility in viewpoint. It's rare, and I've often been guilty of digging in for far too long before changing my point of view (like coming around on gay marriage). I'll just address this statement: "That can only be handled with source-based distro such as gentoo. There's no way you could provide.so files of all possible configurations that could be wanted by users on a binary distro."
You already have a solution that seems to work in Gentoo. You're right, in that no single repository will have all the binaries for all the possible combinations, as it grows exponentially with the number of options. When a user needs a new configuration, it will have to be compiled from source. Therefore, a build system for packages has to be part of the package manager. When done building the new package, the user should publish that binary with his signature so that others in the future who might want it can download it from him. This should all be automatic, under the hood.
I think most common configurations users will want will be ones the author's have tested. Going out on your own is asking for trouble. In reality, I'd probably wind up with a mix of PulseAudio and ALSA apps. In the pie-in-the-sky scenario where such a system is in widespread use, I would expect most such binaries to already exist, and in fact be available from the original authors. They'd download faster than from Ubuntu or Debian, because I'd typically have multiple friends downloading to me in parallel, overcoming the asymmetry in upload/download speed.
Nope, can't agree here. The magic library updating spell is called "pkg-manager update" (or whatever you call the new thingy). The updates you get by default are the ones proposed by your repository lists, in order from highest priority to lowest. It should sound pretty familiar.
The difference is repos should only override the.so files a particular particular package uses in extreme cases (almost never), where they're willing to do the testing, and for some reason upstream reason isn't doing their job. The difference between "stable" and "experimental" versions of a distro should just be a flag the user provides the update tool, to guide it in how aggressively to update, not a whole separate version of a distro. This doesn't work today, simply because the various packages share the same.so files, and we can't afford to test all the combinations.
The usual case, for example with openssh or apache, would be that your upstream simply updates from their upstream, who are most likely the actual code maintainers. The first place (usually) any critical openssh bug gets fixed is right in the original openssh source. A critical openssh update should ripple through the various distros automatically, with little required testing by the distro maintainers. This would improve overall security and reduce painful testing and delay. If this would mostly just magically work, because packages use the versions of.so they were tested with. Users would be far more willing to update, improving security and stability at the same time.
A major problem with the current system is that it's very difficult for distro maintainers to update core packages. You're simply not going to see Firefox updated to 4.0 from 3.X in any given version of any distro once it's shipped. Further, users wanting to test 4.0 are likely to find bugs if they update it themselves. In Ubuntu, I always found that the best thing was to compile the latest from source. As if by magic, the bugs that were making Firefox difficult to use would go away. I'm fearing updating this fall, because stuff mostly works now, and after every LTE release, Ubuntu breaks half the stuff I use in their next release. It's a major PITA, enough to almost make me bail on Ubuntu, except the other distros are worse!
Ideally, you could run Gnome 2 and Gnome 3 on the same Ubuntu install, and if you don't like PulseAudio, you just remove it and use ALSA. Nope. It doesn't work that way. All the major applications are linked to PulseAudio, and if you remove it, there goes your movie player music player, etc. In Ubuntu, it even removes "ubuntu-desktop". Good grief! So, what's wrong with letting users have the various packages recompiled for ALSA, and have an "Ubuntu-ALSLA" repo? The problem is it becomes an unrealistic nightmare of package management, simply because you can't have two versions of any.so file at the same time without renaming them. Not only that, but it takes a packaging guru to make this work, and packaging gurus are rare, and have better things to do than worry about a bunch of blind people who hate PulseAudio.
Switching to a more modern distributed package manager would make the distro's jobs far easier. Ubuntu has a whole team doing nothing but Firefox integration. A better package system would dramatically reduce the load on the package maintainers, enabling Canonical to focus on making Ubuntu rock, rather than continuously fighting all the instability that occurs in every non-LTE release. Most Ubuntu devs spend most of their time fighting fires rather than creating new stuff for us to play with. The reason is our ancient package manager.
A modern package manager would make it easier on code developers. While write-once run-anywhere is a bit of a dream, but it partly works in many computer languages, including Java, C, and Python. If my application can compile on Windows, Mac OS X, every version of Linux and even BSD, why is it so hard to packa
The solution here is to only auto-update.so files if there's a serious security problem. This would make packages 10X more stable, reliable, and compatible with future versions of a distro. The disk space is really not an issue.
Nice to hear a well informed reply. I wont try to convince you that there's something wrong in GNU/Linux land. However, you are wrong when you say, "What you seem to want really isn't possible." It's good that you know something of how Android works. It sounds like you know a bit about how the package manager works. So, I assume I'm not wasting time describing solutions to your impossible list of problems.
You said, "You can't just mix and match in one part of a major subsystem and you certainly can't mix Debian and Fedora packages beyond the very end user applications that have no connections into the different plumbing that seperates the two trees of development and that basically static link everything."
Agreed. So don't do that. Instead, use the Zero Install techniques, both the one's they've implemented, and the ones they wish they had time for. I run $100K software packages on Linux boxes from Cadence and Mentor. The exact same executables run on Fedora, Ubuntu, and Debian. The way they accomplish this is statically linking all the way down to the linux kernel interface (maybe they link to libc - not sure). Now doing that would be bad in general, but if you instead run chrooted in a jail, like recently has been done in Ubuntu, and use hard-links to share the various.so files, you can get disk utilization under control. In my experience,.so files don't fill up much disk anyway, so if I have 2 or 3 versions of most.so files, shared across the various apps that use them, it should not be a big problem. My stupid Android phone forces every app to have it's own copy of every.so file, and my 32G of space doesn't seem to be filling up. Now, I'm not saying that getting all of this working, with the various sound drivers and incompatible binary interfaces is easy. However, it is doable, and not rocket science.
You said, "Android packages work because they are very restricted in what they can do. For example, they must be Java; that means they cannot alter any of the system level components." I wrote a few C applications for Android, so no, you're not restricted to Java. Android secures applications at the linux/libc API level, not just at the Java level. We can, and in some cases in Linux land already do this. It's immature technology, so part of the challenge is fleshing it out.
You said, "So replacing part of GNOME would be like replacing the native binary parts of Android, which an.apk can't attempt. They also work because there is only one Android line and it is carefully kept backward compatible." I agree Android locks stuff down, but that's no excuse for Linux. I can run KDE, Gnome, XFCE, and a number of others, all on the same machine, all at the same time, though not on the same display, though there are even some packages which want to help me do that. The problem is that Debian/Fedora/Ubuntu and other binary compiled package distros assume certain.so files will be there, and if they aren't or if they're the wrong version, nothing works. The problem is also that we have a 1960's architecture for where to put files, and that causes my program's.so file to want to be in the same location as your's and all hell breaks loose. Debian want's to compile all the.so files and have one golden, verified version of each, and make all the other packages upgrade to use it. This guarantees that binary packages are not portable between Linux distros. However, there's no good reason to do this other than that we've always done it this way!
Consider our no-so-hypothetical case of a user who wants to run an actual fork of Gnome Shell. In Debian, that will mean compiling from source, unless the fork maintainers do it for you, and even if they do, you'll be stuck recompiling a vast collection of packages that require specific binary interfaces from the specific Gnome Shell version they were tested with. In reality, we're simpl
This slashdot thread is about a major problem which by itself is a major blow to Linux. Obviously, you think everything is just fine, and always will be. If my tone sounds harsh, it's not you, its just the hordes of clones like you that in the end will insure no real change happens that saddens me.
GNU/Linux true believers are incapable of seeing that GNU/Linux is dying, so we should probably not try to talk rationally about it. I've put an insane number of hours into open source GNU/Linux stuff, so seeing it failing hurts me personally. Debian-multimedia? Really? So... you're going to switch your Gnome desktop like Linus wants to, perhaps you will use debian-multimedia to install the latest and greatest Gnome fork, Cinnamon? No, you wont, because it's not possible, but I wont be able to convince you that you couldn't trivially use debian-multimedia to do it. Math like Android's 600K packages vs Debian's 30K packages mean nothing to you. 590K of them are total crap, right? One week to publish to millions of users in Windows or Android versus years in Debian are a mere annoyance, and you prefer the exceptional quality control in Debian on those 30K packages, to any 600K repository of crap. If software authors object to having to rewrite every package for every distro, and having to negotiate with each distro separately for a package to be accepted, it's their problem, right? The top games aren't available on Linux because of the stupidity of the game industry, right?
GNU/Linux is dying, and as much as I'd like to help fix that, true believers in the ancient ways vastly outnumber those of us with enough software design sense to see that GNU/Linux has to change. The year of Linux on the desktop is 2013! Ignore the nay-sayers like me. We're ignorant morons. A million lines of production code I wrote currently in use by customers around the world contributed nothing to my understanding of anything. Hacking Vinux, speech DSP algorithms, and text-to-speech are child's play (the stuff I do for free to benefit GNU/Linx). It's only for the stupid. 26 years of building software, 22 patents, tech lead at one company that went IPO, early contributor to another IPO, and founder of yet another company I sold last year just means I have no clue. Guys like us are simply ignorant, and will be ignored by the vast majority of true believers. That's why Linux is dying.
With a redesign of the package managers to work as a peer-to-peer distributed repository system built on a web of trust, with the pre-compiled binaries you need to run your system the way you want to, GNU/Linux could be the next big thing (or at least bigger than now). It's actually quite involved and given how well you're picking up the whole "git" rewrite of "dpkg", I'll just assume you're not getting it. Actually, you're probably super smart, but simply refuse to believe that the existing GNU/Linux system is not already delivering anything I could possibly be talking about.
This fracturing of the tiny Linux market into Debian/Ubuntu/Fedora/etc and Gnome2/Gnome3/Unity/Cinnamon is just healthy growing pains, right? All this choice is a good thing, and your switching to KDE is just part of what makes GNU/Linxu so great! Gosh I'm glad I get good quality packages from this vibrant innovative community!
I guess my suggestion that the current system is screwed up didn't make you happy. Well, it's screwed up, and I'm sorry about hurting feelings.
The PPA system is great. I used it extensively. It's a bandaid, not a solution. If I want to pull my upstream Gnome packages from a fork of Gnome, good luck making that work with existing pre-compiled Ubuntu binaries. It's simply not possible, not with a custom PPA and a month of compiling 100 custom packages (which no one will be crazy enough to use, because they just want your Gnome hacks, not a new distro), and certainly not with editing your sources.list. The problems are fundamental design decisions made in the early 90's, which were made well for the time, but now are destroying the GNU/Linux community.
The reason this is pie in the sky is guys like you will bury the message, and most people will never understand the problem, or the potential solution. Dpkg is subversion. We need git.
The problems at Gnome are common across much of GNU/Linux these days. I tried as hard as I could, yet failed to get Gnome GTK+ guys to accept (or offer an alternative) an accessibility patch fairly critical to the blind community (allowing icons to have verbal descriptions). It's possible to work with the Debian guys, but unless one of their inner circle is interested in your specific project, you've got no way to reach all the Debian users who want to use what you have to offer. This is partly why Google has 600K apps and Debian has 30K packages. If I want to reach Android geeks, I can be published by next week, and the only real challenge is being noticed among those other 600K apps.
What Linux needs is a rewrite of dpkg, just like Torvalds did when he wrote git and replaced subversion. This concept of upstream golden source is BS. What we need is distributed git-style repositories, where users can easily point their machines to the upstream branch/fork of their choice. That way, if I'm in my favorite distro and I hate this new desktop manager, I just point to the branch/fork maintained by people I consider more sensible. Machines shouldn't be GNU/Linux boxes. They should be bare metal Linux boxes, and groups like Ubuntu should just be famous repository managers who get so much right for most users, that lazy geeks like me put them first in my list of distributed repositories. But when Fedora has a better package, or a better version, I should be free to pull that specific part from them, and have it work with all the stuff I pull from Ubuntu.
NOT impossible. Only pie in the sky because of the lack of will to move forward in the calcified GNU/Linux community.
Really good posts on this thread! I had not read about the Tragedy of the commons before. What a great tool for understanding all the sh*t that happens in the world. It justifies what I've been saying about various global problems. We wont do anything about global warming until the impact of global warming is already greater than the cost of doing something. At that point, we'll vote for politicians who promise to do something, and pat ourselves on the back for not being one of the morons that caused the mess.
The tragedy of the commons explains perfectly what I've been saying about nuclear energy. We'll keep burning coal, oil, and natural gas as long as it's cheaper than alternatives, even though we're poisoning the air and warming the planet. We wont research promising technologies, like thorium molten salt reactors, until we're already up the creek, and are running out of cheap enriched uranium.
So, even if safe cheap nuclear energy is the answer to global warming and the energy crisis, we're not going to build it, not until we feel the pain.
I've come around to believing nuclear energy could be the answer. Molten salt reactors seem safe, and look like a cheap alternative to our current LWRs. They also provide an answer for what to do about most of the waste from our existing plants. I know most people are focused on solving technical challenges, but assuming we do, here's my biggest concern. Will we have people competent to run them? I live near the Shearon Harris plant, which some people consider the most dangerous in the country. Westinghouse built a great plant, and any moron could run it. It's a good thing, since our plant is run by Homer Simpson. A liquid salt reactor requires on-site fuel processing, and the people doing this probably need to be smart. What happens when we let Homer Simpson try to get the fuel mix just right? That scares the hell out of me.
The above comments were unusually clueless, so here's a new topic, way at the bottom.
Do any of the previous posters have any actual experience dealing with memristors? My phone rang off the hook when this BS story hit the Internet a few years ago. I worked at QuckLogic, where we built "memristors", but failed to have the marketing brilliance to call them anything other than "antifuses". I don't blame the guy at HP who did pull this off. That's how the game is played.
Here's reality. "Memristors" are the basis of Actel and QuickLogic antifuse based FPGAs. We had them characterized years before they were discovered by HP. The more charge you put through them, the lower the resistance. If you put current the other way, the resistance goes up. It was somewhat linear, so I have to beat myself up for not calling them memristors.
HP won the marketing round. However, people now have high expectations for this technology making something useful. If they want to make programmable logic out of it, they should talk to someone like me.
Molten salt reactors are passively safe. If they get too hot, the molten salt melts a plug and drains into a storage tank where it cools and solidifies. Unlike PWRs, nothing's under pressure, greatly reducing risk and cost. Cost adjusted for inflation, the US spent only $35M on the technology before shutting it down for political reasons. The program far exceeded it's goals and expectations, though there was a costly mistake due to ignorance of what could go wrong when it was shut down, resulting in something like a $150M cleanup effort later on.
As I'm sure you know, the nuke site also has the nation's largest storage pools for nuclear waste, which is one reason they're keen on expanding here. It wouldn't bother me that much, but the plant seems to be run by Homer Simpson. I wish they'd take the billions of dollars in old school nuclear expansion and funnel it into some decent molten salt reactor R&D.
Slashdot Mirror
I look for places to use my math skills, and find plenty. I was differentiating to find minimums this morning, and I've used a lot of calculus, linear algebra, and even number theory recently. However, I could find plenty of work which requires nothing more than knowledge of how to use a 4-function calculator. I just don't personally find such work very satisfying.
I've been instrumental in hiring decisions of couple of dozen programmers by now. If a person says math isn't their thing, it's not the end of the interview, though strong math skills are a plus. I'll often be interested in a physics Ph. D. or mathematician, even if they don't yet know how to code, but if a guy can't show strong analytic skills in math, I need to see some demonstration of coding skills. For example, a person with strong 3-D visualization skills can become a good router guy without advanced math skills, though they have to be competent in high school level math. We just put such people on projects that wont require advanced math.
In our work (chip design related algorithms), we have to have some serious math geeks, but it doesn't have to be the whole team. We've got a brilliant IIT grad who did our sparse matrix backwards Trapezoid interconnect delay simulator, running 1000X faster than SPICE, with the same accuracy. There's some cool discrete math in our logic optimizer. The linear algebra in the placer is cool. We're also doing some analog design aids, and it really helps if you understand the math behind the algorithms you're expected to code, and analog optimization is heavily mathematical. Advanced logic optimization some advanced math, as does many algorithms that come up in chip design. I've been doing a bit of analog, which is heavy into Z transforms, and Laplace transforms. I've also recently done a bit of signal processing involving custom optimized FFT code. Transformer design can be done by "rule of thumb", but to write the code to do it well requires solid understanding of both the physics and the math behind it. Those who enjoy advanced math appreciate being assigned projects where they can put their mathematical reasoning skills to good use, and those who hate math appreciate not being on those projects. It all works out. You just need a good mix.
I suspect you are right. The growth curve for solar beats all the other alternatives, and if it keeps on this path, we'll all have cheap solar energy in a decade or two. However, I think we need to invest in the whole spectrum of alternatives. Molten salt reactors, for example, show some promise of lowering costs while dramatically improving safety and offering a solution to the waste disposal problem. It might be pie in the sky, but I'd fund research with my tax dollars.
You are 100% correct. The dorks who don't know that solar is cost effective in certain markets simply haven't researched it. However, most of us don't live in southern California deserts. Contributing factors there include federal and state subsidies, and insanely high regular electric rates, as well as reliable, intense sunlight, which provides power when you need it most: during peak demand. Edison has been running solar farms profitably in southern California for decades.
TFA is factually correct. We could generate all the power we need from solar. Run high voltage across the country, and we could provide power to New York from New Mexico. It's just tech pioneered by Brazil in the '70s.
However, no one is saying that solar is currently the cheapest solution for power, or even the cheapest renewable energy. It may get there, but it's not yet. We could power the country on solar. We could do it with wind. We could do it with geothermal, or gen IV nuclear. I think we need to invest in them all, and let the best technology win. Unfortunately, the reality is we'll continue polluting the planet until even stupid people realize it's a bad idea.
It sounds somewhat similar to Debian and Ubuntu that way. You definitely work your way up. I was a long time RedHat and then a Fedora fan. RedHat's doing well and making money from open source, so I consider them a huge success story. On the other hand, they are strongly invested in keeping business as usual. They are the number 1 solution for business Linux needs. As such, they're the platform that gets the most testing from commercial Linux software vendors. The (unfortunately major) changes I'm talking about would enable software vendors to run on all the Linux distros, eliminating a major market barrier, and likely cutting into RedHat profits. Just about any distro would be more stable, and new features added to one distro could easily be installed to another, again reducing market barriers. I admire the RedHat guys, but I think leveling the playing field in Linux would be against their best interest.
Just thought you should know.
Unless you have unusual needs, you will find life just fine with the existing packaging managers. Porn, BitTorrent downloads, music, you name it. It's all there for a horny 20-year-old.
I'm not blind, and never will be, which makes me somewhat hesitant to complain. I'm simply suffering from central vision loss, which is very much preferable to real blindness. Now, if you were losing sight, and had to depend on future Linux distros to make their shit accessible, you'd be all good about that, right? Because every single system out there is so accessible to the blind! I'll mention Gnewsense, just because you might have heard of them. They would love to support people with vision disorders, but they can't. It's not their fault. RMS is all for Gnewsense, and all for accessibility, but it doesn't fucking work!
The reason it does not work is the stupidity in our current packaging managers.
Actually, I live in Chapel Hill, NC, quite close to RedHat HQ. I've never met anyone in person who works for RedHat. If you know someone I should talk to, I'm just crazy enough to call/e-mail them. Not that I'm looking for a new job... I have significant responsibilities in helping my current one succeed. However, I'd be interested in meeting people living near me who are as you describe.
I've had even a bit more wine, so this idea is even dumber, but here's the brain fart... guys like you who get it, probably because of real experience as a developer, could form a new e-mail group. I suspect there are enough of us out there to make a difference for GNU/Linux.
I just had a stupid somewhat wine-induced brain-fart. What if those of us with substantial experience developing code for Linux who fear for it's future somehow got together on an e-mail group free of the pesky hoards of newbies without a clue? If we could filter out the "everything is perfect, just the way it is" crowd, we might be able to build a community capable of saving GNU/Linux. Note I say GNU/Linux, because Linux on it's own has a bright future without us.
The problem with Linux is guys with a clue like you don't get moderated up on slashdot. For every author of several books on Linux, there are 1,000 newbie Linux fanatics with mod points who don't appreciate your lack of vision.
Thank God there are a few sensible people left in Linux land... Unfortunately, they out-number and out-moderate us.
I think I'm noticing a dividing line between the die-hard "it's perfect the way it is" crowd and those who seem to think distributing software in Linux could be improved: I'm guessing you write software, rather than package software for your particular favorite distro. It's authors who are getting screwed.
OK, I haven't run Cadence on many machines, so I believe you are correct. The Mentor binaries, OTOH, link in just about everything, including their own Java libraries. The benefit is it just works, pretty much everywhere.
So... you installed Ubuntu 12.04, and downgraded to Gnome 2.0 with a simple apt command with no problems? The mechanism to make all this work exists. All it requires is for every author of every package to do extra work for every distro and get it right. No problem, right? And, of course, even if you get it to install OK, you'll be running combinations of .so libraries that no author has ever tested. Good luck with that.
Glad to see your showing some flexibility in viewpoint. It's rare, and I've often been guilty of digging in for far too long before changing my point of view (like coming around on gay marriage). I'll just address this statement: "That can only be handled with source-based distro such as gentoo. There's no way you could provide .so files of all possible configurations that could be wanted by users on a binary distro."
You already have a solution that seems to work in Gentoo. You're right, in that no single repository will have all the binaries for all the possible combinations, as it grows exponentially with the number of options. When a user needs a new configuration, it will have to be compiled from source. Therefore, a build system for packages has to be part of the package manager. When done building the new package, the user should publish that binary with his signature so that others in the future who might want it can download it from him. This should all be automatic, under the hood.
I think most common configurations users will want will be ones the author's have tested. Going out on your own is asking for trouble. In reality, I'd probably wind up with a mix of PulseAudio and ALSA apps. In the pie-in-the-sky scenario where such a system is in widespread use, I would expect most such binaries to already exist, and in fact be available from the original authors. They'd download faster than from Ubuntu or Debian, because I'd typically have multiple friends downloading to me in parallel, overcoming the asymmetry in upload/download speed.
Nope, can't agree here. The magic library updating spell is called "pkg-manager update" (or whatever you call the new thingy). The updates you get by default are the ones proposed by your repository lists, in order from highest priority to lowest. It should sound pretty familiar.
The difference is repos should only override the .so files a particular particular package uses in extreme cases (almost never), where they're willing to do the testing, and for some reason upstream reason isn't doing their job. The difference between "stable" and "experimental" versions of a distro should just be a flag the user provides the update tool, to guide it in how aggressively to update, not a whole separate version of a distro. This doesn't work today, simply because the various packages share the same .so files, and we can't afford to test all the combinations.
The usual case, for example with openssh or apache, would be that your upstream simply updates from their upstream, who are most likely the actual code maintainers. The first place (usually) any critical openssh bug gets fixed is right in the original openssh source. A critical openssh update should ripple through the various distros automatically, with little required testing by the distro maintainers. This would improve overall security and reduce painful testing and delay. If this would mostly just magically work, because packages use the versions of .so they were tested with. Users would be far more willing to update, improving security and stability at the same time.
A major problem with the current system is that it's very difficult for distro maintainers to update core packages. You're simply not going to see Firefox updated to 4.0 from 3.X in any given version of any distro once it's shipped. Further, users wanting to test 4.0 are likely to find bugs if they update it themselves. In Ubuntu, I always found that the best thing was to compile the latest from source. As if by magic, the bugs that were making Firefox difficult to use would go away. I'm fearing updating this fall, because stuff mostly works now, and after every LTE release, Ubuntu breaks half the stuff I use in their next release. It's a major PITA, enough to almost make me bail on Ubuntu, except the other distros are worse!
Ideally, you could run Gnome 2 and Gnome 3 on the same Ubuntu install, and if you don't like PulseAudio, you just remove it and use ALSA. Nope. It doesn't work that way. All the major applications are linked to PulseAudio, and if you remove it, there goes your movie player music player, etc. In Ubuntu, it even removes "ubuntu-desktop". Good grief! So, what's wrong with letting users have the various packages recompiled for ALSA, and have an "Ubuntu-ALSLA" repo? The problem is it becomes an unrealistic nightmare of package management, simply because you can't have two versions of any .so file at the same time without renaming them. Not only that, but it takes a packaging guru to make this work, and packaging gurus are rare, and have better things to do than worry about a bunch of blind people who hate PulseAudio.
Switching to a more modern distributed package manager would make the distro's jobs far easier. Ubuntu has a whole team doing nothing but Firefox integration. A better package system would dramatically reduce the load on the package maintainers, enabling Canonical to focus on making Ubuntu rock, rather than continuously fighting all the instability that occurs in every non-LTE release. Most Ubuntu devs spend most of their time fighting fires rather than creating new stuff for us to play with. The reason is our ancient package manager.
A modern package manager would make it easier on code developers. While write-once run-anywhere is a bit of a dream, but it partly works in many computer languages, including Java, C, and Python. If my application can compile on Windows, Mac OS X, every version of Linux and even BSD, why is it so hard to packa
The solution here is to only auto-update .so files if there's a serious security problem. This would make packages 10X more stable, reliable, and compatible with future versions of a distro. The disk space is really not an issue.
Nice to hear a well informed reply. I wont try to convince you that there's something wrong in GNU/Linux land. However, you are wrong when you say, "What you seem to want really isn't possible." It's good that you know something of how Android works. It sounds like you know a bit about how the package manager works. So, I assume I'm not wasting time describing solutions to your impossible list of problems.
You said, "You can't just mix and match in one part of a major subsystem and you certainly can't mix Debian and Fedora packages beyond the very end user applications that have no connections into the different plumbing that seperates the two trees of development and that basically static link everything."
Agreed. So don't do that. Instead, use the Zero Install techniques, both the one's they've implemented, and the ones they wish they had time for. I run $100K software packages on Linux boxes from Cadence and Mentor. The exact same executables run on Fedora, Ubuntu, and Debian. The way they accomplish this is statically linking all the way down to the linux kernel interface (maybe they link to libc - not sure). Now doing that would be bad in general, but if you instead run chrooted in a jail, like recently has been done in Ubuntu, and use hard-links to share the various .so files, you can get disk utilization under control. In my experience, .so files don't fill up much disk anyway, so if I have 2 or 3 versions of most .so files, shared across the various apps that use them, it should not be a big problem. My stupid Android phone forces every app to have it's own copy of every .so file, and my 32G of space doesn't seem to be filling up. Now, I'm not saying that getting all of this working, with the various sound drivers and incompatible binary interfaces is easy. However, it is doable, and not rocket science.
You said, "Android packages work because they are very restricted in what they can do. For example, they must be Java; that means they cannot alter any of the system level components." I wrote a few C applications for Android, so no, you're not restricted to Java. Android secures applications at the linux/libc API level, not just at the Java level. We can, and in some cases in Linux land already do this. It's immature technology, so part of the challenge is fleshing it out.
You said, "So replacing part of GNOME would be like replacing the native binary parts of Android, which an .apk can't attempt. They also work because there is only one Android line and it is carefully kept backward compatible." I agree Android locks stuff down, but that's no excuse for Linux. I can run KDE, Gnome, XFCE, and a number of others, all on the same machine, all at the same time, though not on the same display, though there are even some packages which want to help me do that. The problem is that Debian/Fedora/Ubuntu and other binary compiled package distros assume certain .so files will be there, and if they aren't or if they're the wrong version, nothing works. The problem is also that we have a 1960's architecture for where to put files, and that causes my program's .so file to want to be in the same location as your's and all hell breaks loose. Debian want's to compile all the .so files and have one golden, verified version of each, and make all the other packages upgrade to use it. This guarantees that binary packages are not portable between Linux distros. However, there's no good reason to do this other than that we've always done it this way!
Consider our no-so-hypothetical case of a user who wants to run an actual fork of Gnome Shell. In Debian, that will mean compiling from source, unless the fork maintainers do it for you, and even if they do, you'll be stuck recompiling a vast collection of packages that require specific binary interfaces from the specific Gnome Shell version they were tested with. In reality, we're simpl
This slashdot thread is about a major problem which by itself is a major blow to Linux. Obviously, you think everything is just fine, and always will be. If my tone sounds harsh, it's not you, its just the hordes of clones like you that in the end will insure no real change happens that saddens me.
GNU/Linux true believers are incapable of seeing that GNU/Linux is dying, so we should probably not try to talk rationally about it. I've put an insane number of hours into open source GNU/Linux stuff, so seeing it failing hurts me personally. Debian-multimedia? Really? So... you're going to switch your Gnome desktop like Linus wants to, perhaps you will use debian-multimedia to install the latest and greatest Gnome fork, Cinnamon? No, you wont, because it's not possible, but I wont be able to convince you that you couldn't trivially use debian-multimedia to do it. Math like Android's 600K packages vs Debian's 30K packages mean nothing to you. 590K of them are total crap, right? One week to publish to millions of users in Windows or Android versus years in Debian are a mere annoyance, and you prefer the exceptional quality control in Debian on those 30K packages, to any 600K repository of crap. If software authors object to having to rewrite every package for every distro, and having to negotiate with each distro separately for a package to be accepted, it's their problem, right? The top games aren't available on Linux because of the stupidity of the game industry, right?
GNU/Linux is dying, and as much as I'd like to help fix that, true believers in the ancient ways vastly outnumber those of us with enough software design sense to see that GNU/Linux has to change. The year of Linux on the desktop is 2013! Ignore the nay-sayers like me. We're ignorant morons. A million lines of production code I wrote currently in use by customers around the world contributed nothing to my understanding of anything. Hacking Vinux, speech DSP algorithms, and text-to-speech are child's play (the stuff I do for free to benefit GNU/Linx). It's only for the stupid. 26 years of building software, 22 patents, tech lead at one company that went IPO, early contributor to another IPO, and founder of yet another company I sold last year just means I have no clue. Guys like us are simply ignorant, and will be ignored by the vast majority of true believers. That's why Linux is dying.
With a redesign of the package managers to work as a peer-to-peer distributed repository system built on a web of trust, with the pre-compiled binaries you need to run your system the way you want to, GNU/Linux could be the next big thing (or at least bigger than now). It's actually quite involved and given how well you're picking up the whole "git" rewrite of "dpkg", I'll just assume you're not getting it. Actually, you're probably super smart, but simply refuse to believe that the existing GNU/Linux system is not already delivering anything I could possibly be talking about.
This fracturing of the tiny Linux market into Debian/Ubuntu/Fedora/etc and Gnome2/Gnome3/Unity/Cinnamon is just healthy growing pains, right? All this choice is a good thing, and your switching to KDE is just part of what makes GNU/Linxu so great! Gosh I'm glad I get good quality packages from this vibrant innovative community!
I guess my suggestion that the current system is screwed up didn't make you happy. Well, it's screwed up, and I'm sorry about hurting feelings.
The PPA system is great. I used it extensively. It's a bandaid, not a solution. If I want to pull my upstream Gnome packages from a fork of Gnome, good luck making that work with existing pre-compiled Ubuntu binaries. It's simply not possible, not with a custom PPA and a month of compiling 100 custom packages (which no one will be crazy enough to use, because they just want your Gnome hacks, not a new distro), and certainly not with editing your sources.list. The problems are fundamental design decisions made in the early 90's, which were made well for the time, but now are destroying the GNU/Linux community.
The reason this is pie in the sky is guys like you will bury the message, and most people will never understand the problem, or the potential solution. Dpkg is subversion. We need git.
The problems at Gnome are common across much of GNU/Linux these days. I tried as hard as I could, yet failed to get Gnome GTK+ guys to accept (or offer an alternative) an accessibility patch fairly critical to the blind community (allowing icons to have verbal descriptions). It's possible to work with the Debian guys, but unless one of their inner circle is interested in your specific project, you've got no way to reach all the Debian users who want to use what you have to offer. This is partly why Google has 600K apps and Debian has 30K packages. If I want to reach Android geeks, I can be published by next week, and the only real challenge is being noticed among those other 600K apps.
What Linux needs is a rewrite of dpkg, just like Torvalds did when he wrote git and replaced subversion. This concept of upstream golden source is BS. What we need is distributed git-style repositories, where users can easily point their machines to the upstream branch/fork of their choice. That way, if I'm in my favorite distro and I hate this new desktop manager, I just point to the branch/fork maintained by people I consider more sensible. Machines shouldn't be GNU/Linux boxes. They should be bare metal Linux boxes, and groups like Ubuntu should just be famous repository managers who get so much right for most users, that lazy geeks like me put them first in my list of distributed repositories. But when Fedora has a better package, or a better version, I should be free to pull that specific part from them, and have it work with all the stuff I pull from Ubuntu.
NOT impossible. Only pie in the sky because of the lack of will to move forward in the calcified GNU/Linux community.
Really good posts on this thread! I had not read about the Tragedy of the commons before. What a great tool for understanding all the sh*t that happens in the world. It justifies what I've been saying about various global problems. We wont do anything about global warming until the impact of global warming is already greater than the cost of doing something. At that point, we'll vote for politicians who promise to do something, and pat ourselves on the back for not being one of the morons that caused the mess.
The tragedy of the commons explains perfectly what I've been saying about nuclear energy. We'll keep burning coal, oil, and natural gas as long as it's cheaper than alternatives, even though we're poisoning the air and warming the planet. We wont research promising technologies, like thorium molten salt reactors, until we're already up the creek, and are running out of cheap enriched uranium.
So, even if safe cheap nuclear energy is the answer to global warming and the energy crisis, we're not going to build it, not until we feel the pain.
I've come around to believing nuclear energy could be the answer. Molten salt reactors seem safe, and look like a cheap alternative to our current LWRs. They also provide an answer for what to do about most of the waste from our existing plants. I know most people are focused on solving technical challenges, but assuming we do, here's my biggest concern. Will we have people competent to run them? I live near the Shearon Harris plant, which some people consider the most dangerous in the country. Westinghouse built a great plant, and any moron could run it. It's a good thing, since our plant is run by Homer Simpson. A liquid salt reactor requires on-site fuel processing, and the people doing this probably need to be smart. What happens when we let Homer Simpson try to get the fuel mix just right? That scares the hell out of me.
The above comments were unusually clueless, so here's a new topic, way at the bottom.
Do any of the previous posters have any actual experience dealing with memristors? My phone rang off the hook when this BS story hit the Internet a few years ago. I worked at QuckLogic, where we built "memristors", but failed to have the marketing brilliance to call them anything other than "antifuses". I don't blame the guy at HP who did pull this off. That's how the game is played.
Here's reality. "Memristors" are the basis of Actel and QuickLogic antifuse based FPGAs. We had them characterized years before they were discovered by HP. The more charge you put through them, the lower the resistance. If you put current the other way, the resistance goes up. It was somewhat linear, so I have to beat myself up for not calling them memristors.
HP won the marketing round. However, people now have high expectations for this technology making something useful. If they want to make programmable logic out of it, they should talk to someone like me.
I think you're confusing molten salt reactors with liquid metal fast breeder reactors. Every molten metal fast breeder program has resulted in failure.
Molten salt reactors are passively safe. If they get too hot, the molten salt melts a plug and drains into a storage tank where it cools and solidifies. Unlike PWRs, nothing's under pressure, greatly reducing risk and cost. Cost adjusted for inflation, the US spent only $35M on the technology before shutting it down for political reasons. The program far exceeded it's goals and expectations, though there was a costly mistake due to ignorance of what could go wrong when it was shut down, resulting in something like a $150M cleanup effort later on.
As I'm sure you know, the nuke site also has the nation's largest storage pools for nuclear waste, which is one reason they're keen on expanding here. It wouldn't bother me that much, but the plant seems to be run by Homer Simpson. I wish they'd take the billions of dollars in old school nuclear expansion and funnel it into some decent molten salt reactor R&D.