Definitely a somber kick off to what was supposed to be a relaxing weekend. Terrible news, i'll always remember the early days of Slashdot as a community of well intentioned budding techs who thought we knew it all... Slashdot was our hub; and roblimo our conductor... That time will always fill me with fondness.
Actually, the protest are because unarmed men, women and children are being killed and not receiving justice. So far, most of the people these protest are about haven't broken any law and further for the outliers; As a nation, we don't kill our citizens when they break the law. We bring them to the altar and scales of justice. As an ex soldier, I find your commentary appalling as well as the behavior of anyone who is against these football players protesting. It's absolutely shameful.
"but is it reasonable for her to deprive her child of the support and help of someone he loved just because that person said something stupid?"
Yes, you see, here is the crux of the problem. What is said is hurtful, tasteless and beyond the privilege afforded to your sister in this case. The child might have loved the person your sister portrayed and your sister might have even been the best intellectually disabled volunteer walking planet Earth. She may not have even meant it in that light. However she disowned all of that by making hurtful comments about her own work, that she could even mouth the words to see them in that light is the problem. So, the child may have been deprived of the most awesome disabled volunteer to walk this planet, but it was your sister whose actions caused that behavior. We all make mistakes, and mistakes have consequences. Some more grave than others. It's a lesson most children learn early, some a little later than others and in this case a lot later.
Is the mob always right? Of course not, but in this case and your sister's.. spot on.
Part of the problem is that it's not better at handle higher loads reliably. Much of what they are doing is basic stuff to improve performance. They could improve performance even more if they stored required data in Varnish instead of memcache and use the remaining mem for other more important things. Of course it sounds like they are now learning about parallel programming so it'll be a while before they get there.
I've written Cobol code; it is neither easy to develop for or succinct; in any manner. Neither is anything seamless. I'm not sure which COBOL you were using but if you could point it out for me I'll and correct me that would be great.
The problem isn't really Perl. The problem is that Perl was used to create applications that aren't maintainable. That combined with the fact that Perl allows any programmer to do anything and you end up with a confused mess. This is not to say I haven't seen some decently coded Perl applications, but they are few and far between. That goes for most any language but even more so with Perl as people have consistently tried to do things in Perl it wasn't meant for.
You end up with codebases that try for OO in syntax alone, poorly and wildly differing formatted code, race conditions, etc etc. Part of this is design but the bigger issue is that Perl wasn't designed originally for that space.
Unless you have a team dedicated explicitly to X version of Perl with X modules and classes and that have a strong structure and background in best programming practices. Any Perl application will turn into a nightmare; more quickly than any other language.
All of the above combined with the fact that web frameworks in general are non existent for Perl. As it was used literally as glue language (a space between Shell and C), and if you needed a framework; you built your own, which is usually a mistake because you NEED strong OO in a web framework. After going through that exercise it's obvious why all of the strongly based OO languages picked up frameworks much faster than Perl.
I was giving you the benefit of the doubt. I'm guessing that since you decided to block quote large paragraphs of detailed argument and instead change the subject you have no response. As for the interface logic, I never said simple. I even admitted it'll be more logic (and thus more complexity). However critical sections are HARD, interfaces aren't as hard. If I have roughly the same amount of each, I'll take the less hard stuff instead of the more hard stuff.
True to form, said obviously by someone who has either never attempted to write such an interface or thinks that because there is more complexity it is conducive to a lesser amount of code. Anyone who has written such an interface will tell you that the API in and of itself is a difficult thing to get right far less doing all of this in some magic codeball and having everything interface to that through the holy grail api.
Large clusters aren't the debate. We're talking large unix systems, i.e. single large systems. Managing in kernel data and processes is a lot harder than stuff running in userspace with a defined interface. We're talking about the difference between spinlocks/semaphores/mutexes/futexes/etc and a messaging interface.
True to form, said obviously by someone who thinks this will somehow be magically abstracted into the kernel by some sort of magical code above that is inertly complex but smaller and will allow easier to write interfaces so that people don't have to worry about deadlocking and all sorts of other problems inherent with writing threaded parallel code and or in general worrying about any of that stuff.
Listen, good luck. You're the same person Linus and everyone else who does this for a living talks about. You negate real world examples of failure, all the microkernel designs currently implemented have failed to compete on the level of monolithic kernels. Why do you persist with these arguments without taking steps to prove them is the question? Have you and Tanenbaum and all the other Microkernel is the bestest learned absolutely nothing over the past 20 years? At the very least take all of the opencode that exists and make a microkernel that competes. Please don't say Minix 3; please.
About as much as anything you said about OSX. Which wouldn't have been relevant anyhow since OSX isn't a microkernel, and only marginally behaves like one.
That's fair but that's all I had as a relevant data-point; or at least close to one when it comes to the largely deployed likish microkernel. It's hard to compare or prove an idea or theory when such a kernel doesn't exist at large in comparison to say the numerous monolithic kernels currently in operation. That said, point taken.
And none of that has anything to do with monolithic versus microkernel, except perhaps tangentially. Microkernels do not ask each device driver to be a server all its own with zero code reuse, they use generic servers to wrap drivers for specific hardware while still isolating them from kernel space. This means there's no functional difference to the driver programmer from a monolithic to a microkernel architecture, either way you look at the driver interface and write the necessary code.
You claim i'm an uninformed pontificator yet you argue this point.
Why do you suddenly need more code to the same thing? Andy's point is that when you stop sharing data structures, and instead start passing messages from one discrete server to another through well defined interfaces you reduce the amount of complexity (and therefor code) involved in protecting the coherency of those data structures. You will end up with more interfaces, but thats not necessarily a bad thing. I'd gladly trade all of the critical section protection logic for some nice interface logic. Especially since making the latter work reliably is a hell of a lot easier to do, and gives each subsystem the freedom to rework their internals without requiring me to lift a finger.
You claim i'm an uninformed pontificator yet you argue this point as well? Good luck; let me know how that works for you. When you get that simple interface logic and everything "working reliably as hell".
There's still no credible evidence to suggest that microkernel performance is that horrible, especially with modern clock speeds. Aside from gaming and large scientific compute clusters, very little being done today on a computer uses any significant measure of their speed. We've already covered how you're totally off base on device support (i.e. its orthogonal to the entire debate), and you throw "management nightmare" out there without bothering to define it, let alone defend it.
There's no credible evidence? The only credible evidence that exists thus far proves that microkernel performance is slower to monolithic kernels; Hurd, Darwin etc. Is device support now orthogonal to the entire debate? Is the whole debate now the specific holy grail algorithm to manage all of the communication that needs to take place? All the access to data structure, shared memory? Again, i'm pontificating?
Large unix systems are already complex as hell to manage. A lot of that complexity is "hidden" in the kernel, which while fine for desktop users is a big pain for system administrators, and would be exposed for manageability in a microkernel setup.
You're seriously smoking some good crack. As much as large unix systems are complex as hell to manage. You think a microkernel design will make them easier to manage? This is some really good crack here. 9 times out of 10 on large cluster systems it isn't the kernel that is the problem, 9 times out of 10 it is management. 9 times out of 10 you WANT monolithic in a large cluster. No wonder the drug cartels are doing so well.
As for OS X and its performance, its not horribly slow. Especially considering that your complaint almost certainly centers around PPC performance not x86, where it was hampered by lower clock speeds that were not counterbalanced by better IPC in any significant fashion. OS X's memory hunger has little to do with the kernel and lots to do with their operating environment, and all of the gee whiz graphical functionality that OS X brings along with it.
?? I said load programs into mem. Please re-read what I wrote.. Just put the crack pipe down and re-read it.
Ultimately though, OSX performance is a success story because on a G3 700mhz with 256M of ram its actually useable. Have you tried running Windows XP on a similar setup? Tried turning all of the eye candy on? Bet you didn't like the way it performed either.
These arguments have been heard before and i'm not exactly sure where this is going?
Micro-kernels sound good, they sound real good. Maybe for desktop systems and the like it isn't that bad of an idea. At least it seems that way on the surface, i'm not really sure Tanenbaum has taken a look at all the facets involved in a modern day system or at least he seems to be neglecting the uphill climb. For small embedded environments where speed or device support isn't a main concern. Micro-kernels will excel for their stability but take a look around and that's not reality or what we have today. We have lots of different hardware, lots of different interfaces and to manage that all via objects it'll just be extremely large.
If you think the linux kernel is big the relevant code for this would be numerous times larger. It just pushes the code from the kernel into userspace and you will definitely need more code to manage and access data structure. So then you'll have to create some sort of server to interact with this piece and that piece of the kernel, to get this piece of information. Linus is right, and has been right on this argument for some time. I'm not of the mindset that it can't be done. If you can isolate your facets and only plan on supporting X number of devices/platforms/chipsets/etc and don't expect any blazing performance. Microkernels are great. Beyond that? With the rate that technology moves, it just becomes a management nightmare.
I don't understand how things have changed since this original argument was made? Faster hardware makes a difference in this argument, but not a major one. The points that should be addressed are manageability, growth and sharing. None of which have been addressed really besides the darwin kernel; OS X. Which as successful as it is, proves at least one point. The performance is extremely slow. With more memory it's not as bad but still; slow. I'm not even sure why Linus responded in the first place.
So true, this combined with the fact that by the time you get to test a "new" kernel release, there is already a new release. Then everyone starts bitching about how no one is testing each others patches. I'm with you. so i'll throw in my vote for the old system infact again, this should be officially addressed. The old system was indeed, melded for stability. This new "stable" just really means. It compiled on MOST platforms, not all.
Initially I knew it would eventually devolve into this but everyone was saying extremely large or new features would be able to get alot more testing. That's not happening though, the amount of people testing each release is different and then you have people like me who have to sit around and deal with or work around bugs, which you'd never suspect lead back to the kernel but low and behold, its becoming more and more common, especially with new chipsets. Then the effort involved in diagnosing and reporting takes time, sometimes weeks and in extreme cases months. By that time we are on a new release already.
You sir are a wise man. No one even thinks along the lines of shooting a m16 at 1000 yards. It's like driving a city bus off road. It just makes no goddamn sense.
That must of been a pretty big bullseye. So much for the Navy Shooting team, if true then I can only recommend you guys continue to stay on the ship and in your airplanes during battle and leave the more fine art of sniping and killing to us professionals in the army/marines because you got lucky.
Again, please leave the blood bathing to people more inclined to use the right tool for the job. "Always Forward!" not "Always in the pool!"
I have to call bullshit on this.. Only because i've tried, numerous times to fire the m16 at many things over 600 yds. With an M16 you're pushing it even at 300 yds far less 600 yds. Static or not, and even if you account for wind and elevation unless you're scientifically placing your shots and getting rounds off you WILL miss. I know, because I've done it. There are too many factors, too many variables and the M16 simply doesn't have a long enough barrel to be accurate with any sort of regularity. You can get pretty good at 300-400 yds if you know your weapon but that's it.
As a practical choice for 200+ yds it's indeed a fine weapon once you account for your own weapon tendencies. You can easily drop into a forward prone and set off rounds with accuracy at 200-300 yds. If you're speaking about from the top shooting you can still be even pretty accurate with the weapon but in combat no one is stupid enough to give the other side a half mast easy kill.
Also, all this 1000 yd talk is obviously for people who've never fired the m16. I mean, 1000 yds with a m16, if you actually hit your target it's because you were lucky. As some other poster was saying.. You can let mortars fly and they may even hit the target but how often does that happen? It's like saying you hit something with a m60.. It's used not for its accuracy as a weapon but to surpress fire while lets say snipers or other units position themselves for more accurate kills.
And snipers in the army do not use M16's.. Some of them have an affinity for their AR-15's.. some of them use M24's.. both come equipped with scopes and for the most part you're looking for 700-800 yd range and not 1000 yds or whatever nonsense people are talking above. Someone shooting with an m16 at 1000 yds and claiming accuracy is obviously lying; not even a sniper would try that. It's just clearly lunacy.
Someone just needs to want change bad enough.
on
Perils of DNS at RIPE-52
·
· Score: 2, Interesting
The vulnerabilties of DNS have been expounded on forever, people already know this. The survey then goes on to point out how trust is an issue and for all that the conclusion of this survey is that cryptographic name to address bindings are key. That's only part of the solution.
The bigger problem is clearly TRUST and can be alleviated if the DNS system was simply reimplemented. Easier said that done, yes, but a p2p with a trust metric system applied isn't overtly complicated and would scale. For instance, lets say you want example.com. It would be delegated when you register, propogated by it's trust amongst the root servers and the two or more namservers you've added when you've signed up. You then setup the trust system algo to prevent large attacks or changes.
The benefits are numerous, the roots are still the roots but are less taxed; their main purpose? The ultimate in trust so that subsequent nameservers always follow the trust metric and should a rogue amount decide to disobey trust metric they are flagged and dropped.
The only problem is actually doing it and setting up some sort of migration path.
Listen, I hate Gates just as much as the next guy (maybe even more) but he is right this time and I suspect it's because of his experience with his wife. Her fulltime job is to better the world and half the shit she must whine about is involved with giving away money he's shanked for.
I'm sure he has his own ideas on how technology could better 3rd world countries. Which probably involve some crap Microsoft has that doesn't work. It still doesn't negate the fact that in this instance, on this topic he is right and most people in the know; agree.
Maybe Negroponte is just looking for a cheaper laptop, in which case none of this matters. It's the idea that this will do anything for imporvished nations that really gets people. You can save a link to this slashdot post and in 10 years come back for validation.
Hi. don't you see a little problem with the fact that he was off fighting a war for his country (from the time he was 14)? Maybe he would of had more time to learn about AIDS had he not been packing mags, slinging rounds?
Bet he knows alot more about an AK or AR than you. So yes, he probably had no idea how AIDS was spread but he knows he can shoot an AK clear for 4-5 mags without jams or barrel sieze. So with that said, how is a $100 dollar laptop going to help him? Do you think he's going to magically look up AIDS and how it's spread?
Ignorance is the problem, sure.. education can help. The laptop isn't going to cure ignorance. I'm sure, a laptop wasn't used in communicating to him how the spread of AIDS occurs. +5 Insightful my ass.
Surely, you're educated enough to come to your own conclusion.
I really wanted to refrain from commenting on this because I believe a large portion of Slashdot regardless of how well read and worldly they believe themselves to be; simply are not. That and the fact i'm aware of my own tedencies to turn a logical, well thought out and reasoned answer into a gun battle. However;
A $100 dollar computer in some of these "3rd world" countries won't even GET to the people that would be able to use them for the purposes of learning and expanding because:
1. Those people are being SLAUGHTERED. 2. Trying to save their families or their own lives. 3. Trying to feed themselves. 4. Finding food. 5. Finding shelter in war settings. 6. Looking for water. 7. Fighting disease.
When you are hungry, thirsty and don't have the hiearchy of needs the Maslow theory claims is universal. You are clearly not going to be interested in someone putting $100 dollars worth of equipment in your hand. It is completely useless to you if it doesn't do any of the above. You're going to maybe want someone to put $100 dollars worth of food in its place. What has the UN and the rest of the "civilized" industrialized world been doing in the last couple of years? Nothing. Absolutely, positively, nothing. Most of the food is consistently taken over by local ganglords, you have 3rd party outsiders destabilizing countries for natural resources, most organizations and even the UN peacekeepers themselves are corrupt. Luring small children with the promises of milk and raping them. It astonishes me you have the gall to sit there and talk about $100 dollar fucking computers with exhuberance as some sort of holy grail.
You, Negroponte and all the other "YEAH YEAH $100 dollars will better educational access idiots" need some reality. Reality in the sense that you need to spend some time in the same countries you think you're doing any favors for. I guarantee you, after spending a couple weeks in one of those places the last thing on your mind is going to be some $100 dollar computer. Infact, on your return I suspect you'd fascinate on something as simple as a bottle of water, ice, the variety of food and such.
Want to help with software and technology? Take an example from a project like Vim and donate money for food, clothes, antibiotics and vaccines. Then pray 10% of the stuff reaches the people that need it.
Please, please, don't mod this insightful; it is not. Not even close.
Its not that things cannot be fixed - they can, look at Michael Meek's glibc patches. Its that the community don't recognize the problems -> for example: Michael Meek's patches was rejected/ignored.
It hasn't been out and out rejected. Meeks has been making his case regarding support for it and it'll either be accepted by Ulrich eventually or not. If it compromises the stability and operation of GlibC it won't get in. If the patch will break alot of situations, it won't get in. If it's ugly.. won't get in. One could go on. Just because you and your people are candy happy you get x% of performance doesn't mean the patch doesn't have to be tested/explained/verified to work under X conditions before its accepted into something like GlibC. Which could take a long long time. So please, stop bringing up Michael Meeks and his patches; christ.
Unless the distro people and many people in the community recognize that the incompatibilities are unacceptable, things won't get fixed, and I'm afraid Linux will not succeed on the desktop until that happens. For instance, one of my classmates, who recently installed a Linux distro, complained about how hard it is to install software on Linux.
If you want Linux on the desktop here's what I recommend. You get a copy of the coreutils/tools you need and FORK them. Add all the little patches that you want, throw in all the goodies. Build up some decent framework, build out the api's for kde/qt gnome/gtk and use it. Problem solved. Stop bitching about Linux on the desktop because people like me? kernel developers, gcc hackers, linux users from inception.. even newbie die hards.. DO. NOT. CARE. I use what works and if it doesn't work I either hack it to my satisfaction or move to something that does work.
Linux suceeding on the desktop? I don't care. Your mom can't make a partition? I don't care. You can't burn a cd without the command line? I don't care. If you care; do something about it. Stop bitching.
That isn't the point. Try running a C++ binary, which was compiled on distro X, on distro Y. If you're lucky, it works. If you're not lucky, it crashes for mysterious reasons. This is caused by C++ ABI breakages and ELF symbol conflicts.
What causes the abi breakages and elf symbol conflicts? Would it be that a package belonging to one distro is different from the next distro. You aren't making any valid point here. I've read the autopackage stuff pretty extensively before deciding to make a package for GnomeMeeting aka Ekiga with it and low in behold. GnomeMeeting and the libs it requires are for the most part written in C++. Autopackage couldn't handle creating a openh323 package because of whatever bug. This is another discussion however. Back to C++ ABI breakages, you are arguing about two pieces of software glibc and gcc. If one is compiling with GCC these are things they should be aware of. YES there will be ABI breakage. As you, i've come to disagree with several things regarding the breakage and the seemingly ideoligical change of what is supposed to work no longer working and/or vice versa; et al. This still doesn't make your argument on incompability valid in any manner.
Notice that I mentioned the word "technical" several times. So yes we know what we're talking about. If you don't believe us, feel free to proof read our technical documents and proof us wrong.
Technically you are trying to fix something that Autopackage or your methods will not fix. So pissing up a rope isn't something i'd get into. Originally I thought the idea of autopackage was excellent but after realizing that it just won't work I stopped wasting my time. It's a good idea, it just won't work in this current environment. Unless you start to take the reigns of many different subsystems and stick them into one framework you are bound by. In essence you'd be doing what Apple is doing now.
Anyway, that was just to prove you that the C++ binary problems exist and are real.
According to you, yes. Which obviously leads into your very important point...
Open source software DO need to be able to distribute cross-distribution binaries
I humbly disagree. It would be nice though.
The need to distribute cross-distribution binaries isn't specific to proprietary software, as too many people seem to believe. Normal users don't, and shouldn't have to, care about compiling. It is their right - after all, they may have a legitimate reason to not learn it (too busy with work, for example). Therefore, the ability to easily install applications (without compiling!) is a good thing.
There are many package installers for whatever distro; What you are suggesting makes no sense the way things are going. Distributions have become so specific that trying to create cross distribution binaries just makes no sense. Well, unless you can control the above. As I previosuly stated. Autopackage is a good idea, it just will not work without you either making your own distribution, which would defeat the whole purpose. Or, getting everyone to place nice and accept all your patches for unification. Which would no doubt work for you but break alot of other things. Again, I thought about this myself whilst reading over autopackage sometime ago and i'm certainly no laymen when it comes to the topics you speak of.
This implies that we cannot rely the distribution to take care of *all* the packaging. Its simply not possible, there is not enough manpower for that. I'm not saying that distributions should not package software, but it should be possible for the upstream (open source!) developers to distribution binaries (for their open source software!).
Nothing is stopping any open source devleoper from distributing binaries for their open source software unless you consider the state of things stopping them. In which case, you'd have a point but as this is the third time i'm saying. I don't believe any one person or even company for that matter has the resour
Driver API. Centralised driver development doesn't work - period. Assume the existance of a totally awesome vendor who is happy to release GPLd drivers with their new widget. They put a penguin on the side of the box. They immediately get their ass sued off by people who buy the widget, plug it into Goobuntu or whatever, nothing happens and for some reason they aren't satisfied by the explanation of "Well it'll Just Work in 12 months when the driver has been accepted upstream, been merged with your distros kernel patches, and you upgrade your OS". They want it to work now damnit, and Windows/MacOS can do this so why can't Linux?
First and foremost having a Driver API is pointless as has been pointed out by numerous people time and time again. Sadly you make it seem like windows users can buy whatever "widget" and just plug it in. We all know that isn't true and most "widgets" come with the appropriate drivers for said widget. Secondly, If the manufacturer hasn't updated the driver or provided a driver for the latest kernel then so be it. It's no different than anything else. You buy a widget for win95/98 then don't expect it to work with 2000/XP unless its extremely basic.
Yet the kernel developers do exactly this for drivers, and threaten (or actually do) sue random vendors who distribute binary drivers (except not nVidia, as that'd cause mass civil war).
Distribute binary drivers without source? Without access to source, but you still are using GPL code? It's normally called violation of the GPL.
Is Nvidia breaking any rules? No, they abide by the rules. So what are you talking about? It's ok for vendors to violate the GPL?
C++ support. It doesn't work. It's unbelievably slow, the glibc developers refuse patches to fix it, and is only reliable as long as you use "pure" binaries built with the same compiler that everything else is. This makes robust binary distribution of C++ apps impossible and as nearly every large desktop app is written in C++ this is a problem.
Performance I won't comment on it, Glibc developers refusing patches I won't comment on because we all know at the end of the day it boils down to support of code, support of diff platforms and one could go on. However binary distribution of C++ apps impossible? Give me a break. You speak as if upgrading the core components of a system are a daily tasks for the user. We have packages for that and the distribution compiles the code and makes a binary package for the distribution!!! See, thats easy. If you're favorite software has been updated then wait for your disitribution to update it. No different than having to wait for Office 2009! Same thing.
No easy install/uninstall - if you're comfortable with partitioning etc then you can get Fedora installed without too much bother, but Ubuntu doesn't even have a graphical installer, and as far as I'm aware no distro today offers an easy way to remove it and put Windows back to 100% disk usage. Who in their right mind would try a program that ate 10gigs of disk space and didn't come with a way to uninstall it?
Are you kidding me? Does ANYTHING allow you an easy way to remove windows/linux/whatever and put Windows back to 100% disk usage? Are users really doing this? Linux is a program that eats 10 gigs of disk space? What ever happened to LiveCD's? They no longer exist? Have you seen the Windows Installer? What in gods name are you saying?
No credible DRM support. Every major company that deals with media uses it, Microsoft and Apple support it and Linux sucks at it. This effectively freezes Linux out from the upcoming world of legal online media (music/video stores etc).
Name a media format Linux cannot play; name one.
You could go on, i'm sure. You could go on spouting off untruths and general crap. Don't get me wrong there are items of contention when it comes to opensource and frameworks. One could only hope there were a company or distribution that took c
1. You work for a defense contractor who will then sponsor your investigation. 2. You were part of the DoD and already got one; pretty much if you were in the military at any given point working on an installation that required that sort of investigation. You're pretty much covered. 3. You are a retired army general and are starting your own defense contractor business. In which case you probably don't have to ask for one.
Disclaimer; I used to work on an intelligence battalion when I was in the army.
In most cases, you're not getting one. Even if you do work for a defense contractor they won't sponsor your investigation unless it's absolutely required and you are going to be working on the most important part of the project for a long amount of time. Which wont happen unless you've been with the contractor themselves for quite some time. Top Secret investigation can take about 6 months.
The only way to truly get one is to join a DoD, FBI, NSA branch and do military intel/comm/mp etc etc. Or, work directly on a project of some importance being one of the few knowledgable or with sufficient skill to get it done. It's a good ole boy network, defense. Probably one of the oldest and well known. Honestly, its probably for the best that it stay that way.
Slashdot Mirror
Definitely a somber kick off to what was supposed to be a relaxing weekend. Terrible news, i'll always remember the early days of Slashdot as a community of well intentioned budding techs who thought we knew it all... Slashdot was our hub; and roblimo our conductor... That time will always fill me with fondness.
Actually, the protest are because unarmed men, women and children are being killed and not receiving justice. So far, most of the people these protest are about haven't broken any law and further for the outliers; As a nation, we don't kill our citizens when they break the law. We bring them to the altar and scales of justice. As an ex soldier, I find your commentary appalling as well as the behavior of anyone who is against these football players protesting. It's absolutely shameful.
"but is it reasonable for her to deprive her child of the support and help of someone he loved just because that person said something stupid?"
Yes, you see, here is the crux of the problem. What is said is hurtful, tasteless and beyond the privilege afforded to your sister in this case. The child might have loved the person your sister portrayed and your sister might have even been the best intellectually disabled volunteer walking planet Earth. She may not have even meant it in that light. However she disowned all of that by making hurtful comments about her own work, that she could even mouth the words to see them in that light is the problem. So, the child may have been deprived of the most awesome disabled volunteer to walk this planet, but it was your sister whose actions caused that behavior. We all make mistakes, and mistakes have consequences. Some more grave than others. It's a lesson most children learn early, some a little later than others and in this case a lot later.
Is the mob always right? Of course not, but in this case and your sister's.. spot on.
Part of the problem is that it's not better at handle higher loads reliably. Much of what they are doing is basic stuff to improve performance. They could improve performance even more if they stored required data in Varnish instead of memcache and use the remaining mem for other more important things. Of course it sounds like they are now learning about parallel programming so it'll be a while before they get there.
I've written Cobol code; it is neither easy to develop for or succinct; in any manner. Neither is anything seamless. I'm not sure which COBOL you were using but if you could point it out for me I'll and correct me that would be great.
The problem isn't really Perl. The problem is that Perl was used to create applications that aren't maintainable. That combined with the fact that Perl allows any programmer to do anything and you end up with a confused mess. This is not to say I haven't seen some decently coded Perl applications, but they are few and far between. That goes for most any language but even more so with Perl as people have consistently tried to do things in Perl it wasn't meant for.
You end up with codebases that try for OO in syntax alone, poorly and wildly differing formatted code, race conditions, etc etc. Part of this is design but the bigger issue is that Perl wasn't designed originally for that space.
Unless you have a team dedicated explicitly to X version of Perl with X modules and classes and that have a strong structure and background in best programming practices. Any Perl application will turn into a nightmare; more quickly than any other language.
All of the above combined with the fact that web frameworks in general are non existent for Perl. As it was used literally as glue language (a space between Shell and C), and if you needed a framework; you built your own, which is usually a mistake because you NEED strong OO in a web framework. After going through that exercise it's obvious why all of the strongly based OO languages picked up frameworks much faster than Perl.
I was giving you the benefit of the doubt. I'm guessing that since you decided to block quote large paragraphs of detailed argument and instead change the subject you have no response. As for the interface logic, I never said simple. I even admitted it'll be more logic (and thus more complexity). However critical sections are HARD, interfaces aren't as hard. If I have roughly the same amount of each, I'll take the less hard stuff instead of the more hard stuff.
True to form, said obviously by someone who has either never attempted to write such an interface or thinks that because there is more complexity it is conducive to a lesser amount of code. Anyone who has written such an interface will tell you that the API in and of itself is a difficult thing to get right far less doing all of this in some magic codeball and having everything interface to that through the holy grail api.
Large clusters aren't the debate. We're talking large unix systems, i.e. single large systems. Managing in kernel data and processes is a lot harder than stuff running in userspace with a defined interface. We're talking about the difference between spinlocks/semaphores/mutexes/futexes/etc and a messaging interface.
True to form, said obviously by someone who thinks this will somehow be magically abstracted into the kernel by some sort of magical code above that is inertly complex but smaller and will allow easier to write interfaces so that people don't have to worry about deadlocking and all sorts of other problems inherent with writing threaded parallel code and or in general worrying about any of that stuff.
Listen, good luck. You're the same person Linus and everyone else who does this for a living talks about. You negate real world examples of failure, all the microkernel designs currently implemented have failed to compete on the level of monolithic kernels. Why do you persist with these arguments without taking steps to prove them is the question? Have you and Tanenbaum and all the other Microkernel is the bestest learned absolutely nothing over the past 20 years? At the very least take all of the opencode that exists and make a microkernel that competes. Please don't say Minix 3; please.
About as much as anything you said about OSX. Which wouldn't have been relevant anyhow since OSX isn't a microkernel, and only marginally behaves like one.
That's fair but that's all I had as a relevant data-point; or at least close to one when it comes to the largely deployed likish microkernel. It's hard to compare or prove an idea or theory when such a kernel doesn't exist at large in comparison to say the numerous monolithic kernels currently in operation. That said, point taken.
And none of that has anything to do with monolithic versus microkernel, except perhaps tangentially. Microkernels do not ask each device driver to be a server all its own with zero code reuse, they use generic servers to wrap drivers for specific hardware while still isolating them from kernel space. This means there's no functional difference to the driver programmer from a monolithic to a microkernel architecture, either way you look at the driver interface and write the necessary code.
You claim i'm an uninformed pontificator yet you argue this point.
Why do you suddenly need more code to the same thing? Andy's point is that when you stop sharing data structures, and instead start passing messages from one discrete server to another through well defined interfaces you reduce the amount of complexity (and therefor code) involved in protecting the coherency of those data structures. You will end up with more interfaces, but thats not necessarily a bad thing. I'd gladly trade all of the critical section protection logic for some nice interface logic. Especially since making the latter work reliably is a hell of a lot easier to do, and gives each subsystem the freedom to rework their internals without requiring me to lift a finger.
You claim i'm an uninformed pontificator yet you argue this point as well? Good luck; let me know how that works for you. When you get that simple interface logic and everything "working reliably as hell".
There's still no credible evidence to suggest that microkernel performance is that horrible, especially with modern clock speeds. Aside from gaming and large scientific compute clusters, very little being done today on a computer uses any significant measure of their speed. We've already covered how you're totally off base on device support (i.e. its orthogonal to the entire debate), and you throw "management nightmare" out there without bothering to define it, let alone defend it.
There's no credible evidence? The only credible evidence that exists thus far proves that microkernel performance is slower to monolithic kernels; Hurd, Darwin etc. Is device support now orthogonal to the entire debate? Is the whole debate now the specific holy grail algorithm to manage all of the communication that needs to take place? All the access to data structure, shared memory? Again, i'm pontificating?
Large unix systems are already complex as hell to manage. A lot of that complexity is "hidden" in the kernel, which while fine for desktop users is a big pain for system administrators, and would be exposed for manageability in a microkernel setup.
You're seriously smoking some good crack. As much as large unix systems are complex as hell to manage. You think a microkernel design will make them easier to manage? This is some really good crack here. 9 times out of 10 on large cluster systems it isn't the kernel that is the problem, 9 times out of 10 it is management. 9 times out of 10 you WANT monolithic in a large cluster. No wonder the drug cartels are doing so well.
As for OS X and its performance, its not horribly slow. Especially considering that your complaint almost certainly centers around PPC performance not x86, where it was hampered by lower clock speeds that were not counterbalanced by better IPC in any significant fashion. OS X's memory hunger has little to do with the kernel and lots to do with their operating environment, and all of the gee whiz graphical functionality that OS X brings along with it.
?? I said load programs into mem. Please re-read what I wrote.. Just put the crack pipe down and re-read it.
Ultimately though, OSX performance is a success story because on a G3 700mhz with 256M of ram its actually useable. Have you tried running Windows XP on a similar setup? Tried turning all of the eye candy on? Bet you didn't like the way it performed either.
What does this has to do with the kernel?
These arguments have been heard before and i'm not exactly sure where this is going?
Micro-kernels sound good, they sound real good. Maybe for desktop systems and the like it isn't that bad of an idea. At least it seems that way on the surface, i'm not really sure Tanenbaum has taken a look at all the facets involved in a modern day system or at least he seems to be neglecting the uphill climb. For small embedded environments where speed or device support isn't a main concern. Micro-kernels will excel for their stability but take a look around and that's not reality or what we have today. We have lots of different hardware, lots of different interfaces and to manage that all via objects it'll just be extremely large.
If you think the linux kernel is big the relevant code for this would be numerous times larger. It just pushes the code from the kernel into userspace and you will definitely need more code to manage and access data structure. So then you'll have to create some sort of server to interact with this piece and that piece of the kernel, to get this piece of information. Linus is right, and has been right on this argument for some time. I'm not of the mindset that it can't be done. If you can isolate your facets and only plan on supporting X number of devices/platforms/chipsets/etc and don't expect any blazing performance. Microkernels are great. Beyond that? With the rate that technology moves, it just becomes a management nightmare.
I don't understand how things have changed since this original argument was made? Faster hardware makes a difference in this argument, but not a major one. The points that should be addressed are manageability, growth and sharing. None of which have been addressed really besides the darwin kernel; OS X. Which as successful as it is, proves at least one point. The performance is extremely slow. With more memory it's not as bad but still; slow. I'm not even sure why Linus responded in the first place.
So true, this combined with the fact that by the time you get to test a "new" kernel release, there is already a new release. Then everyone starts bitching about how no one is testing each others patches. I'm with you. so i'll throw in my vote for the old system infact again, this should be officially addressed. The old system was indeed, melded for stability. This new "stable" just really means. It compiled on MOST platforms, not all.
Initially I knew it would eventually devolve into this but everyone was saying extremely large or new features would be able to get alot more testing. That's not happening though, the amount of people testing each release is different and then you have people like me who have to sit around and deal with or work around bugs, which you'd never suspect lead back to the kernel but low and behold, its becoming more and more common, especially with new chipsets. Then the effort involved in diagnosing and reporting takes time, sometimes weeks and in extreme cases months. By that time we are on a new release already.
You sir are a wise man. No one even thinks along the lines of shooting a m16 at 1000 yards. It's like driving a city bus off road. It just makes no goddamn sense.
That must of been a pretty big bullseye. So much for the Navy Shooting team, if true then I can only recommend you guys continue to stay on the ship and in your airplanes during battle and leave the more fine art of sniping and killing to us professionals in the army/marines because you got lucky.
Again, please leave the blood bathing to people more inclined to use the right tool for the job. "Always Forward!" not "Always in the pool!"
I have to call bullshit on this.. Only because i've tried, numerous times to fire the m16 at many things over 600 yds. With an M16 you're pushing it even at 300 yds far less 600 yds. Static or not, and even if you account for wind and elevation unless you're scientifically placing your shots and getting rounds off you WILL miss. I know, because I've done it. There are too many factors, too many variables and the M16 simply doesn't have a long enough barrel to be accurate with any sort of regularity. You can get pretty good at 300-400 yds if you know your weapon but that's it.
As a practical choice for 200+ yds it's indeed a fine weapon once you account for your own weapon tendencies. You can easily drop into a forward prone and set off rounds with accuracy at 200-300 yds. If you're speaking about from the top shooting you can still be even pretty accurate with the weapon but in combat no one is stupid enough to give the other side a half mast easy kill.
Also, all this 1000 yd talk is obviously for people who've never fired the m16. I mean, 1000 yds with a m16, if you actually hit your target it's because you were lucky. As some other poster was saying.. You can let mortars fly and they may even hit the target but how often does that happen? It's like saying you hit something with a m60.. It's used not for its accuracy as a weapon but to surpress fire while lets say snipers or other units position themselves for more accurate kills.
And snipers in the army do not use M16's.. Some of them have an affinity for their AR-15's.. some of them use M24's.. both come equipped with scopes and for the most part you're looking for 700-800 yd range and not 1000 yds or whatever nonsense people are talking above. Someone shooting with an m16 at 1000 yds and claiming accuracy is obviously lying; not even a sniper would try that. It's just clearly lunacy.
Indeed it does, I will have to give this a try.
The vulnerabilties of DNS have been expounded on forever, people already know this. The survey then goes on to point out how trust is an issue and for all that the conclusion of this survey is that cryptographic name to address bindings are key. That's only part of the solution.
The bigger problem is clearly TRUST and can be alleviated if the DNS system was simply reimplemented. Easier said that done, yes, but a p2p with a trust metric system applied isn't overtly complicated and would scale. For instance, lets say you want example.com. It would be delegated when you register, propogated by it's trust amongst the root servers and the two or more namservers you've added when you've signed up. You then setup the trust system algo to prevent large attacks or changes.
The benefits are numerous, the roots are still the roots but are less taxed; their main purpose? The ultimate in trust so that subsequent nameservers always follow the trust metric and should a rogue amount decide to disobey trust metric they are flagged and dropped.
The only problem is actually doing it and setting up some sort of migration path.
Listen, I hate Gates just as much as the next guy (maybe even more) but he is right this time and I suspect it's because of his experience with his wife. Her fulltime job is to better the world and half the shit she must whine about is involved with giving away money he's shanked for.
I'm sure he has his own ideas on how technology could better 3rd world countries. Which probably involve some crap Microsoft has that doesn't work. It still doesn't negate the fact that in this instance, on this topic he is right and most people in the know; agree.
Maybe Negroponte is just looking for a cheaper laptop, in which case none of this matters. It's the idea that this will do anything for imporvished nations that really gets people. You can save a link to this slashdot post and in 10 years come back for validation.
Hi. don't you see a little problem with the fact that he was off fighting a war for his country (from the time he was 14)? Maybe he would of had more time to learn about AIDS had he not been packing mags, slinging rounds?
Bet he knows alot more about an AK or AR than you. So yes, he probably had no idea how AIDS was spread but he knows he can shoot an AK clear for 4-5 mags without jams or barrel sieze. So with that said, how is a $100 dollar laptop going to help him? Do you think he's going to magically look up AIDS and how it's spread?
Ignorance is the problem, sure.. education can help. The laptop isn't going to cure ignorance. I'm sure, a laptop wasn't used in communicating to him how the spread of AIDS occurs. +5 Insightful my ass.
Surely, you're educated enough to come to your own conclusion.
+1, Correct.
I really wanted to refrain from commenting on this because I believe a large portion of Slashdot regardless of how well read and worldly they believe themselves to be; simply are not. That and the fact i'm aware of my own tedencies to turn a logical, well thought out and reasoned answer into a gun battle. However;
A $100 dollar computer in some of these "3rd world" countries won't even GET to the people that would be able to use them for the purposes of learning and expanding because:
1. Those people are being SLAUGHTERED.
2. Trying to save their families or their own lives.
3. Trying to feed themselves.
4. Finding food.
5. Finding shelter in war settings.
6. Looking for water.
7. Fighting disease.
When you are hungry, thirsty and don't have the hiearchy of needs the Maslow theory claims is universal. You are clearly not going to be interested in someone putting $100 dollars worth of equipment in your hand. It is completely useless to you if it doesn't do any of the above. You're going to maybe want someone to put $100 dollars worth of food in its place. What has the UN and the rest of the "civilized" industrialized world been doing in the last couple of years? Nothing. Absolutely, positively, nothing. Most of the food is consistently taken over by local ganglords, you have 3rd party outsiders destabilizing countries for natural resources, most organizations and even the UN peacekeepers themselves are corrupt. Luring small children with the promises of milk and raping them. It astonishes me you have the gall to sit there and talk about $100 dollar fucking computers with exhuberance as some sort of holy grail.
You, Negroponte and all the other "YEAH YEAH $100 dollars will better educational access idiots" need some reality. Reality in the sense that you need to spend some time in the same countries you think you're doing any favors for. I guarantee you, after spending a couple weeks in one of those places the last thing on your mind is going to be some $100 dollar computer. Infact, on your return I suspect you'd fascinate on something as simple as a bottle of water, ice, the variety of food and such.
Want to help with software and technology? Take an example from a project like Vim and donate money for food, clothes, antibiotics and vaccines. Then pray 10% of the stuff reaches the people that need it.
Please, please, don't mod this insightful; it is not. Not even close.
Me too.. I'd prefer an oreo.. white center.. and or soft chew chocolate chip please.. mmmmmm cookies.
Its not that things cannot be fixed - they can, look at Michael Meek's glibc patches. Its that the community don't recognize the problems -> for example: Michael Meek's patches was rejected/ignored.
It hasn't been out and out rejected. Meeks has been making his case regarding support for it and it'll either be accepted by Ulrich eventually or not. If it compromises the stability and operation of GlibC it won't get in. If the patch will break alot of situations, it won't get in. If it's ugly.. won't get in. One could go on. Just because you and your people are candy happy you get x% of performance doesn't mean the patch doesn't have to be tested/explained/verified to work under X conditions before its accepted into something like GlibC. Which could take a long long time. So please, stop bringing up Michael Meeks and his patches; christ.
Unless the distro people and many people in the community recognize that the incompatibilities are unacceptable, things won't get fixed, and I'm afraid Linux will not succeed on the desktop until that happens. For instance, one of my classmates, who recently installed a Linux distro, complained about how hard it is to install software on Linux.
If you want Linux on the desktop here's what I recommend. You get a copy of the coreutils/tools you need and FORK them. Add all the little patches that you want, throw in all the goodies. Build up some decent framework, build out the api's for kde/qt gnome/gtk and use it. Problem solved. Stop bitching about Linux on the desktop because people like me? kernel developers, gcc hackers, linux users from inception.. even newbie die hards.. DO. NOT. CARE. I use what works and if it doesn't work I either hack it to my satisfaction or move to something that does work.
Linux suceeding on the desktop? I don't care. Your mom can't make a partition? I don't care. You can't burn a cd without the command line? I don't care. If you care; do something about it. Stop bitching.
That isn't the point. Try running a C++ binary, which was compiled on distro X, on distro Y. If you're lucky, it works. If you're not lucky, it crashes for mysterious reasons. This is caused by C++ ABI breakages and ELF symbol conflicts.
What causes the abi breakages and elf symbol conflicts? Would it be that a package belonging to one distro is different from the next distro. You aren't making any valid point here. I've read the autopackage stuff pretty extensively before deciding to make a package for GnomeMeeting aka Ekiga with it and low in behold. GnomeMeeting and the libs it requires are for the most part written in C++. Autopackage couldn't handle creating a openh323 package because of whatever bug. This is another discussion however. Back to C++ ABI breakages, you are arguing about two pieces of software glibc and gcc. If one is compiling with GCC these are things they should be aware of. YES there will be ABI breakage. As you, i've come to disagree with several things regarding the breakage and the seemingly ideoligical change of what is supposed to work no longer working and/or vice versa; et al. This still doesn't make your argument on incompability valid in any manner.
Notice that I mentioned the word "technical" several times. So yes we know what we're talking about. If you don't believe us, feel free to proof read our technical documents and proof us wrong.
Technically you are trying to fix something that Autopackage or your methods will not fix. So pissing up a rope isn't something i'd get into. Originally I thought the idea of autopackage was excellent but after realizing that it just won't work I stopped wasting my time. It's a good idea, it just won't work in this current environment. Unless you start to take the reigns of many different subsystems and stick them into one framework you are bound by. In essence you'd be doing what Apple is doing now.
Anyway, that was just to prove you that the C++ binary problems exist and are real.
According to you, yes. Which obviously leads into your very important point...
Open source software DO need to be able to distribute cross-distribution binaries
I humbly disagree. It would be nice though.
The need to distribute cross-distribution binaries isn't specific to proprietary software, as too many people seem to believe. Normal users don't, and shouldn't have to, care about compiling. It is their right - after all, they may have a legitimate reason to not learn it (too busy with work, for example). Therefore, the ability to easily install applications (without compiling!) is a good thing.
There are many package installers for whatever distro; What you are suggesting makes no sense the way things are going. Distributions have become so specific that trying to create cross distribution binaries just makes no sense. Well, unless you can control the above. As I previosuly stated. Autopackage is a good idea, it just will not work without you either making your own distribution, which would defeat the whole purpose. Or, getting everyone to place nice and accept all your patches for unification. Which would no doubt work for you but break alot of other things. Again, I thought about this myself whilst reading over autopackage sometime ago and i'm certainly no laymen when it comes to the topics you speak of.
This implies that we cannot rely the distribution to take care of *all* the packaging. Its simply not possible, there is not enough manpower for that. I'm not saying that distributions should not package software, but it should be possible for the upstream (open source!) developers to distribution binaries (for their open source software!).
Nothing is stopping any open source devleoper from distributing binaries for their open source software unless you consider the state of things stopping them. In which case, you'd have a point but as this is the third time i'm saying. I don't believe any one person or even company for that matter has the resour
You're talking out of your ass.
Driver API. Centralised driver development doesn't work - period. Assume the existance of a totally awesome vendor who is happy to release GPLd drivers with their new widget. They put a penguin on the side of the box. They immediately get their ass sued off by people who buy the widget, plug it into Goobuntu or whatever, nothing happens and for some reason they aren't satisfied by the explanation of "Well it'll Just Work in 12 months when the driver has been accepted upstream, been merged with your distros kernel patches, and you upgrade your OS". They want it to work now damnit, and Windows/MacOS can do this so why can't Linux?
First and foremost having a Driver API is pointless as has been pointed out by numerous people time and time again. Sadly you make it seem like windows users can buy whatever "widget" and just plug it in. We all know that isn't true and most "widgets" come with the appropriate drivers for said widget. Secondly, If the manufacturer hasn't updated the driver or provided a driver for the latest kernel then so be it. It's no different than anything else. You buy a widget for win95/98 then don't expect it to work with 2000/XP unless its extremely basic.
Yet the kernel developers do exactly this for drivers, and threaten (or actually do) sue random vendors who distribute binary drivers (except not nVidia, as that'd cause mass civil war).
Distribute binary drivers without source? Without access to source, but you still are using GPL code? It's normally called violation of the GPL.
Is Nvidia breaking any rules? No, they abide by the rules. So what are you talking about? It's ok for vendors to violate the GPL?
C++ support. It doesn't work. It's unbelievably slow, the glibc developers refuse patches to fix it, and is only reliable as long as you use "pure" binaries built with the same compiler that everything else is. This makes robust binary distribution of C++ apps impossible and as nearly every large desktop app is written in C++ this is a problem.
Performance I won't comment on it, Glibc developers refusing patches I won't comment on because we all know at the end of the day it boils down to support of code, support of diff platforms and one could go on. However binary distribution of C++ apps impossible? Give me a break. You speak as if upgrading the core components of a system are a daily tasks for the user. We have packages for that and the distribution compiles the code and makes a binary package for the distribution!!! See, thats easy. If you're favorite software has been updated then wait for your disitribution to update it. No different than having to wait for Office 2009! Same thing.
No easy install/uninstall - if you're comfortable with partitioning etc then you can get Fedora installed without too much bother, but Ubuntu doesn't even have a graphical installer, and as far as I'm aware no distro today offers an easy way to remove it and put Windows back to 100% disk usage. Who in their right mind would try a program that ate 10gigs of disk space and didn't come with a way to uninstall it?
Are you kidding me? Does ANYTHING allow you an easy way to remove windows/linux/whatever and put Windows back to 100% disk usage? Are users really doing this? Linux is a program that eats 10 gigs of disk space? What ever happened to LiveCD's? They no longer exist? Have you seen the Windows Installer? What in gods name are you saying?
No credible DRM support. Every major company that deals with media uses it, Microsoft and Apple support it and Linux sucks at it. This effectively freezes Linux out from the upcoming world of legal online media (music/video stores etc).
Name a media format Linux cannot play; name one.
You could go on, i'm sure. You could go on spouting off untruths and general crap. Don't get me wrong there are items of contention when it comes to opensource and frameworks. One could only hope there were a company or distribution that took c
You can't unless
1. You work for a defense contractor who will then sponsor your investigation.
2. You were part of the DoD and already got one; pretty much if you were in the military at any given point working on an installation that required that sort of investigation. You're pretty much covered.
3. You are a retired army general and are starting your own defense contractor business. In which case you probably don't have to ask for one.
Disclaimer; I used to work on an intelligence battalion when I was in the army.
In most cases, you're not getting one. Even if you do work for a defense contractor they won't sponsor your investigation unless it's absolutely required and you are going to be working on the most important part of the project for a long amount of time. Which wont happen unless you've been with the contractor themselves for quite some time. Top Secret investigation can take about 6 months.
The only way to truly get one is to join a DoD, FBI, NSA branch and do military intel/comm/mp etc etc. Or, work directly on a project of some importance being one of the few knowledgable or with sufficient skill to get it done. It's a good ole boy network, defense. Probably one of the oldest and well known. Honestly, its probably for the best that it stay that way.
There is no such thing as a transparent society.
Freedom is being able to do what you went when you want how you want without anyone knowing or denying anothers freedom.
Include all words that fit in there.
That IS Freedom.
There is no fundamental difference. There is no Utopia, there is no transparent society. There are no what ifs, maybe, likelyhoods.
It is was it is. Maybe in some Alien world they refer to it differently but we live on Earth.