When you ssh from host a to host b (or use SSL through a phone or browser or whatever), you use public key cryto to perform key exchange of a private key crytpto key. That private key crypto key is a RANDOM NUMBER THAT NO ONE CARES ABOUT, and I was explaining that you would not archive a copy of that random number with the government, since, should they desire to tap your email/web browser/phone/ssh/etc., they would only need the private key for the public key cryptosystem you used. At that point, they could grab the plain text of the session which would look something like this:
I am going to use key "F3845B32CBA..." [now follows encrypted data, using the above key...]
so there is absolutely no need to have that private key crypto key on file, as long as the private key associated with the PUBLIC key crypto is in the hands of the authorities, they DON'T NEED ANYTHING ELSE. No warrant, no delay, nothing. Just decrypt and go.
You're misunderstanding the technology or the law (I'm not sure which).
They're talking about private keys (as in the private half of the public/private key pair in public key cryptography), not private keys (as in the only key in private key cryptography).
This is a huge difference. Private key cryptography is used as the underlying scheme for protocols like SSH, SSL, etc, but public key cryptography is used to ensure the secure exchange of that key. of the private half of the key pair is known, that initial exchange is not secure, and thus there is no need to be TOLD the private key cryptosystem's key: it is handed to any listener who knows the private key that goes with the public key used to initiate the session.
Oh, and the cell phone companies almost certainly already hand over the key pairs for the phones (or are issued them).
I think we're missing the point here. This was the system that was TOO RESPECTFUL OF PRIVACY!
This was discontinued in favor of a system which used the same technology, but did not encrypt the information. Sure, this system might have been a problem (it's like searching all cars on the highway, but only arresting the people who have illegal items), but this was tossed out in favor of WORSE.
Which is most of the probblem with this ruling. I don't disagree with it, but we shouldn't be too quick to call it a purely beneficial ruling.
This will mean that small businesses now have VASTLY reduced leverage in court against large companies that steal their patented work. Of course, Creative isn't tiny, but if it were Mom-and-Pop Electronics, Inc. instead, and they had such a patent, they would have no way to claim an amount of damage sufficient to outwheigh the profits that Apple would lose due to a halt on iPod sales.
When I can't tell the difference between a rendered character and a live one, then I'll start wondering if graphics are approaching "good enough".
I think either point of view is based on the assumption that there's a uniform tradeoff. You don't do work on the graphics to the detriment of the playability unless you're on some very odd crack. You develop a game that you think will suit the market.
Of course, anyone that's armchair quarterbacking Carmack's choices on development effort at this point is probably not thinking in terms of reality, anyway.
Time to issue the standard latency vs. bandwith missive, clearly.
What ISPs are selling is latency. Watch the ads: "the page loads / game plays so fast!"
They're not selling bandwidth, even though that's how they inaccurately measure their latency. If they were, then servers would not be an issue.
All of that is moot, however, since there's simple math here:
rate - usage*cost = margin
That is, they are selling a service which costs them a certain amount, and they see some percentage usage. They then charge some rate and the delta between those is the profit margin for them. If you are arguing that they should raise the price and eliminate bandwidth concerns, then that's one thing, but if you are suggesting that they keep prices the same, then clearly they have to control one of usage, cost or margin.
Margins in the ISP business right now aren't spectacular, but they're OK. ISPs certainly aren't looking ot LOWER them, so give up on that point. Then you have usage and cost. The cost is negotiated fairly strongly, but ultimately you have the same argument up-stream with backbones as you have between consumers and their ISPs. Then there's uage. Observe the current trend in attempting to manage usage.
If you really want to be charged for a full 1.5, 3, 5 or whatever you have down, you're going to have to expect that prices will skyrocket! If that's what you want, then what's wrong with tiered service?
From where I stand, the whole argument AGAINST tiered service is that the economies of scale in the averaged cost model favor a single tier of consumer service. Then again, I'm a Speakeasy customer now, so I've essentially opted for tiered service anyway by paying more than your average cable Internet user.
You are missing the point, and for once, I think the MPAA is doing the right thing.
They're not looking for the operation that could be replaced by a guy printing DVDs in his basement. They're looking for the operations that send MILLIONS of DVDs around the world via various shipping services. These folks are the real pirates, and if anyone is actually harming the movie industry through piracy, it is these folks, not the college kid that downloads a shakey hand-cam of MI3.
Now, as for privacy concerns... if you had the illusion that there was privacy with respect to internationally shipped packages, then this bit of cold water to the face is JUST WHAT YOU NEEDED. Internationally shipped packaoges are checked for food items, dangerous materials, drugs, etc, etc. There is NOTHING private about shipping internationally, and has not been for decades.
Applications->Accessories->Text editor; Write script; Save script; Right-click->Properties; Click Permissions tab; turn on execute; Close; Double-click script.
Not everything done through the GUI has to be 100% visual. That's the whole point to combining the metaphors via nautilus scripting and actions, for example.
The point is that when working THROUGH a GUI, you can choose to use a command-line or not as you go, and for the most appropriate jobs.
Here's the part that kills me: open source software got its start by bundling OSS programs with proprietary code. This is the history of BSD (and thus SunOS), the whole GNU toolchain including Emacs and gcc which didn't run on an open source platform until the 90s, X windows (which was mixed with various proprietary software over the years, and has always come out the better for it, or at least unscathed), etc.
Now that there's a working system that can stand on its own, all of a sudden the free software advocates (obviously, not ALL of us) are screaming about how bundling is bad.
Proprietary software and free software, IMHO, should continue to play on equal footing. If we're right about the value of the free software proposition, then we'll find that the proprietary stuff will lose out, but that won't actually happen. There are cases where proprietary software exists because it does not scratch the itch of anyone with the technical expertise or willingness to replace it. In those areas, we'll continue to see thriving closed source code, and that's not a bad thing.
Actually, this isn't the way most moderm microkernels work either. Generally, you talk to a THREAD associated with the driver. This thread adopts the callers slot and priority in the run queue temporarily, and scrutinizes the caller's request (performing roughly the analysis that you suggested, but at the appropriate priority, which might be much lower than some other process that wants the same driver a fraction of a milisecond later).
The request is then either carried out in the handler thread, or passed off to a centralized driver thread after triage.
This *is* more complex (which is Torvalds' point), but it's not horrible. Most of it can be wrapped in macros/templates/whatever and is uniform across all drivers.
I think that Tovalds makes some excellent points, and simplistic arguments like "microkernels are more secure because each part is smaller and simpler," are just that: simplistic. Overly so.
Still, there's value in the microkernel approach, as has been repeatedly shown. I'll remind readers that microkernel's don't all look alike. Most functioning microkernels are hybridized in one way or another with monolithic kernels to achieve usability. In the case of MacOS/X, that involves placing a monolithic kernel on top of the microkernel as a subsystem. In the case of NT/XP/Vista, that involves re-writing the most performance- and security-sensitive subsystems as monolithic subsystems (and, shockingly the NT kernel is about the only place that NT gets security right).
Microkernels are here to stay, as they offer some useful abstractions, but I don't think that they harken the doom of monolithic kernels like Linux. It's just a different approach.
No, the open source effort will fail. That's the bad news. The good news is that the problem will be solved.
The reason that an open source effort will fail is because it's not a software problem. It's a hardware problem. More specifically, it's a problem getting the hardware vendors to support open source products (e.g. OOo on Windows and various ODF-compatible applications under Linux, etc.)
That WILL happen. Once more states, hopefully the U.S. Federal Government, and many foriegn governments start requiring ODF supporting applications, the hardware vendors will want their products to get used, and they will make sure that they work.
Step 1: Move the buyers. Step 2: Let the vendors follow.
You're joking, right? You honestly find those worrysome?
You have a one-character change to playtreeparser.c which, as far as I can tell is a bug fix to user-interface lossage, but worst case scenario displays an error when it should not.
The addition of the string "redhat" (one word change) in configure (sets system_name to Linux).
The removal of a startup status message regarding CPU detection.
Turning on a bi-directional text feature.
Forcing LIRC testing in configure (I assume this is because their build environment might have the LIRC headers and libraries, but no installed/dev/lirc, which is what configure tests for).
What about those is scary?
The only one that sounded sketchy at first was the parameter type change, but on reviewing that, I see that it's not the TYPE, but the parameter NAMES for readv and writev. My guess is that newer versions of gcc are enforcing matching names if names are used. This is probably something that was fixed in later CVS versions, since I assume the project would now have experience with more modern compiler versions.
Indeed... I had not known that. Well, then I suspect they're dead. I can't imagine them reversing their lot on the basis of the SGI brand alone. Perhaps... but it would be a HUGE longshot. The new CEO is almost certainly there to recoup the value of the assets only.
Thanks for the advice. FWIW, I'm running mplayer-1.0-0.26.20060314.fc5 which is built according to the followong spec file:
# cvs -z3 -d:pserver:anonymous@mplayerhq.hu:/cvsroot/mplayer co -P # cvs -z3 -d:pserver:anonymous@mplayerhq.hu:/cvsroot/ffmpeg co -P # cp -a mplayer MPlayer-%{date} # cp -a ffmpeg/{libavcodec,libavformat,libavutil} MPlayer-%{date}/ # find MPlayer-%{date} -name CVS -o -name.cvsignore | xargs rm -rf # tar cjvf MPlayer-%{date}.tar.bz2 MPlayer-%{date}/ Source0: http://www.mplayerhq.hu/MPlayer/cvs/MPlayer-%25{da te}.tar.bz2 %else Source0: http://www.mplayerhq.hu/MPlayer/releases/MPlayer-% 25{version}%{?rcver}.tar.bz2 %endif Source1: http://www.live555.com/liveMedia/public/live.2006. 03.03.tar.gz Source2: http://www.mplayerhq.hu/MPlayer/Skin/Blue-1.5.tar. bz2 # Only for reference, required on YDL4 at least Source10: uio.h-ppc.patch Patch0: MPlayer-0.90pre9-runtimemsg.patch Patch1: MPlayer-0.90-playlist.patch Patch2: MPlayer-0.90pre10-redhat.patch Patch10: MPlayer-1.0pre6a-fribidi.patch Patch11: MPlayer-1.0pre8-udev.patch
Which you can see has 3 primary components, the 20060314 CVS source of mplayer and ffmpeg, liveMedia from 2006.03.03, and the "Blue" skin, as modified by 6 tiny patches which:
Fix 2 function prototypes for the platform
Change an error message so that it appears for 0 entries in a list as well as less than 0
patch configure to recognize "redhat"
change fribidi_flip_commas from 0 to 1 in subreader.c
and force udev checking in configure
So, as you can see, the Fedora install is pretty recent and fairly virgin in the sense that it has almost nothing unique about it. Now, I'm not clear on what liveMedia is, and perhaps that's considered ugly, who knows. But there you have the goods. If someone says "I'm running stock FC5+freshrpms, you now know what they're talking about (of course, the tricky part is the build environment which may or may not have been up-to-date with respect to updates when the package was compiled -- I recomend that you suggest to users that they re-build the SRPM in case of doubt, which is FAIRLY easy, at least compared to a CVS build, which most will botch or give up on).
"I've seen many people that, when told they have a hardware problem, respond, indignantly, that no other software has problems, only MPlayer. Then a few weeks later, you'll see a message from the same person, saying their CPU fan was going out, and appologizing..."
And I'm sure I've done something equally dense in the past... we all fall down sometimes. The thing is that I've been using Linux since pre-1.0 and Unix since the 80s, and I've contributed to open source projects many times... still, I find reporting bugs to mplayer to be daunting because of the time that the project requires that I spend in order to tell them about a bug. That means that, unlike say firefox, mplayer is disconnected from the woes of its userbase, and will mainly get bug reports that it is willing to cope with from developers and bleeding-edge users. This skews the feedback, and you develop a view of the user base which is not consistent with reality.
With fewer barriers to that process, you would get more representitive bug reports, and perhaps "I get seg faults all the time" would not come as such a shock.
"MPlayer's aggressive code makes for the perfect test of any compilier... Every other application on the planet can compile perfectly, and yet you'll find bugs with MPlayer. -O3, -march, lots of ASM, 3dNow, SSE, MMX, etc."
Surely. I would say that you're going to run into cache-related, bus-related, graphics-related and instruction-related issues that VERY few other programs will. That makes it all the more important that you understand the user base, work with the distributions and, where
* New CEO/CFO * Major holders (read investors) get to keep their shares, everyone else gets nothing * They have already reduced their size by $100M, and another $50M is coming (layoffs mostly, I imagine) * They remain optimistic.
IMHO: They are doomed, but if the new CEO isn't just a "make it worth enough to pay off the debt" sort of guy, they could harvest the value of the Cray and SGI brands and parley them into a major product line once again. It would take the vision of a Steve Jobs type, but it could be done.
A side note. If you want anything in terms of debugging information, and you're in a position to actually move my bug report from Slashdot to something useful, I'd be happy to chat via email. I don't have a good sample video file as yet that isn't 300+MB, but drop me a line any time. I'm ajs at the like-named doamin in the dot-com namespace.
You're getting way too upset about this. Please don't take this personally.
I simply said that mplayer (and gmplayer, as you correctly pointed out) crashes for me constantly, and I'm running a completely stock FC5+freshrpms system (and have had similar problems with every Fedora release I've used mplayer on).
Take that as an attack of some sort if you wish, but the fact of the matter is that the reason that I JUST NOW went to read Slashdot is that mplayer crashed at the end of a video file.
If distributions are breaking your software, you need to find out how and get them to fix it, as it is RUINING your reputation for me and anyone else seeing the same problems. If there's a bug... well, you can figure out where I'm going with that one.
I'll try to narrow it down with a small enough sample file that I can send in a bug report at some point, but hundreds of others MUST be seeing this, as I have nothing unusual in installation (fresh hardware and install circa 2-3 weeks ago).
Side note about gcc 2.96 (which I'm not using, I just get kind of touchy about the anti-2.96 comments because it was a vastly misunderstood release): You're bringing up some ancient history here, and yes, there are still buggy versions of 2.96 around (just as with any software), but they were fixed long, long ago. The only compiler bugs that I know of in CURRENT 2.96 versions are those that are endemic to the version (e.g. platform support issues which were addressed with major changes in 3.1+). If your bug reports are coming in from users who are using older revs, then there are workarounds that you could use to fix these issues, but you sound like someone who's not very interested in supporting 2.96 users, so I would suggest to them that they upgrade to the latest updates from their distribution vendor. The suggesting that there are problems with the latest version on that page you pointed to... well, perhaps there are (I'm sure there are in 3.4 or any random version... I assume about a bug per line of code in any software, and gcc has many lines of code), but unless you can narrow that hypothesis a bit more, no one is going to be able to write a fix.
The page that you linked to has some severe misconceptions about the history. I installed 7.0 the week it came out. I recall exactly what the issues were, and other than a few, very early problems that were mostly fixed by 7.1, and all fixed by 7.3, I've never seen a bug that was UNIQUE to 2.96 and did not show up in 3.0 a short while later. Of course, both 3.0 and 2.96 had problems, as they were major changes to gcc (hence the major revision). I would never suggest that someone use 2.96 if they are starting from scratch since it's so old, but if you're using it in a production environment, it's good enough at this point that updating isn't CRUCIAL.
You keep harping on things like gcc 2.96... You do realize that that was released NINE releases ago for what is, in name, and in practice, a completely different product, right?
What's more, if you go back and look at the history, the Red Hat team had a lot of problems with the release of 2.96 (which was a Red Hat (well, really, Cygnus) pre-release of the compiler version that they (along with the community) had been developing for several years under the previous name egcs... 2.96 was the re-merging of 2.x and egcs into 3.0, a once-again-standards-compliant C and C++ compiler suite). The thing was, everyone else proceded to have the exact same problems a few months later when gcc 3.0 was officially released. There WERE some compiler bugs in 7.0's gcc 2.96, but they were minor and fixed quickly. The REAL PROBLEM was that gcc 2.96 and thus gcc 3.0 enforced standards that gcc 2.x had always been lax about, and thus many programs needed small fixes in order to compile correctly. Everyone took this as "Red Hat enforcing their world view" until gcc 3.0 came out and everyone found out that it was the entire gcc community enforcing the standards.
2.96 was the only stable compiler for Sparc, Alpha and MIPS under Linux at the time. 2.96 was not an option for that reason, and Red Hat had a scheduled release date to make. They were in a tight spot, and they made, IMHO, the right call. The soon released minor releases of 7.1, 7.2 and 7.3 brought much improved versions of the compiler suite and 2.96 is STILL used in many production environments because of its massive improvements in the implementation of C++ without the later experimental features of the 3.1+ releases. The folks at Cygnus took a huge beating for what was ultimately a very well managed release that caused only minor headaches in reality, and they revitalized the gcc project which had stagnated pre-egcs, due to the political tensions between the C and C++ as well as the Intel and non-Intel worlds.
So, if you're going to tell a user that their problems aren't problems, but rather stupid platform issues that the player can't possibly do anything but seg fault on, you might want to talk about the current day and modern compiler releases, or at least not parrot the bad mythology of a few who have an axe to grind against a company that has done more for open source than any 100 of the axe grinders in question.
"As I said, segfaults are very rare these days. Most of the time segfaults are reported, it's buggy hardware (hot CPU, RAM, videocard, etc.) or a known-buggy version of GCC (2.96, 3.3, etc)."
About half of the time that I hit "stop" and close the player on a valid AVI, it seg faults. If I try to play corrupted AVI files (which it should choke on), it seg faults (which it should not do, as that indicates a failure in bounds checking that could be very dangerous if viewing untrusted content). These are common behaviors on multiple machines, one of which is brand new. I've used FC3, FC4 and FC5 without a change in behavior and I have never compiled a custom version of the player (I've used the Fedora and/or FreshRPMS versions only), and are thus compiled with fairly modern compiler versions (circa the distribution release + updates) and I update on a frequent basis from updates, extras, freshrpms and, where applicable, legacy.
I'm a fairly routine user doing fairly routine things, and a dialog with a "signal 11" error is routine for me. What are the developers doing differently that seg faults are so rare for them? Are they only using carefully crafted test files? Are they running with some special libraries or compiler versions? Is there an unreleased fix?
The good news is that Gnutella continues to run strong. I actively share a few Gigabytes of free content including operating systems, free music, public domain image archives and so on via gtk-gnutella which you can acquire from the sourceforge project pages for the gtk-gnutella project. Open up both TCP and UDP ports inbound for whatever port you choose to operate it on, and it performs at least as well as bittorrent, but with amazingly useful searching and filtering options.
The gtk-gnutella folks (who do an excellent job, but could always use more contributors) spend a fair amount of time working out counters for spamming and poisoning techniques.
Obviously, you're not a fan of Eberron, but I think the setting has promise. It makes several bold moves and at the same time, it retains compatibility with other D&D settings and the system as a whole.
I like the warforged for several reasons:
*They're not just "humans made of metal" (role playing not withstanding) *They impose unique needs on players *Their background isn't based on mysterious, powerful "ancients" who are gone now *They can add as much or as little steampunkishness as you like
The other races are fairly par for the course, but I don't dislike any of them. The fact that some otherwise minor monsters (e.g. Rakshasa) play a major part in the world is nice. The use of dragons was fairly novel, but not overbearing (such as the way they were used in Arcana Evolved, which is a very nice system modification, but sometimes grating as a setting for me).
Overall, it's just a high-magic D&D world like you would expect, and I think it caps off the spectrum nicely when viewed in combination with the other D&D worlds including Greyhawk (I run a game set here), Forgotten Realms (I love the basic concept, but haven't been able to make the time yet to dive in), Dragonlance (not a fan personally, but I know a few people who enjoyed it), Ravenloft (S&S did some good work on this, under their license from WotC), etc.
"This is funny, it almost sounds from the article that they changed their methodology to increase their claimed "losses", and had to rein them back in when they discovered their losses exceeded global Gross (International) Product."
You are failing to comprehend the depth of the crisis! The international economy's shortfall in this respect is costing the movie industry TRILLIONS! If only Turkey had a gross national product of 82 gigabucks, surely half of it would have been spent on copies of movies that people already owned, but had no moral right to either duplicate or simply stop re-watching!
This is a crime, and make no mistake... there is going to be a law! The only realistic solution at this point is to cede control of the World Monetary Fund to the MPAA.
I'm constantly running into segfaults in mplayer. I don't know if it's just a whacky codec or what, but no matter what the input, no player should ever segfault on any media. If it does, that means that memory is being handled poorly, and that's a potential opportunity for an attack vector.
Slashdot Mirror
And how popular was your open source movie?
It's always trivial to cut down the work of another, but if you can't do better, is there really any point?
You are misunderstanding the technology.
When you ssh from host a to host b (or use SSL through a phone or browser or whatever), you use public key cryto to perform key exchange of a private key crytpto key. That private key crypto key is a RANDOM NUMBER THAT NO ONE CARES ABOUT, and I was explaining that you would not archive a copy of that random number with the government, since, should they desire to tap your email/web browser/phone/ssh/etc., they would only need the private key for the public key cryptosystem you used. At that point, they could grab the plain text of the session which would look something like this:so there is absolutely no need to have that private key crypto key on file, as long as the private key associated with the PUBLIC key crypto is in the hands of the authorities, they DON'T NEED ANYTHING ELSE. No warrant, no delay, nothing. Just decrypt and go.
You're misunderstanding the technology or the law (I'm not sure which).
They're talking about private keys (as in the private half of the public/private key pair in public key cryptography), not private keys (as in the only key in private key cryptography).
This is a huge difference. Private key cryptography is used as the underlying scheme for protocols like SSH, SSL, etc, but public key cryptography is used to ensure the secure exchange of that key. of the private half of the key pair is known, that initial exchange is not secure, and thus there is no need to be TOLD the private key cryptosystem's key: it is handed to any listener who knows the private key that goes with the public key used to initiate the session.
Oh, and the cell phone companies almost certainly already hand over the key pairs for the phones (or are issued them).
I think we're missing the point here. This was the system that was TOO RESPECTFUL OF PRIVACY!
This was discontinued in favor of a system which used the same technology, but did not encrypt the information. Sure, this system might have been a problem (it's like searching all cars on the highway, but only arresting the people who have illegal items), but this was tossed out in favor of WORSE.
Which is most of the probblem with this ruling. I don't disagree with it, but we shouldn't be too quick to call it a purely beneficial ruling.
This will mean that small businesses now have VASTLY reduced leverage in court against large companies that steal their patented work. Of course, Creative isn't tiny, but if it were Mom-and-Pop Electronics, Inc. instead, and they had such a patent, they would have no way to claim an amount of damage sufficient to outwheigh the profits that Apple would lose due to a halt on iPod sales.
When I can't tell the difference between a rendered character and a live one, then I'll start wondering if graphics are approaching "good enough".
I think either point of view is based on the assumption that there's a uniform tradeoff. You don't do work on the graphics to the detriment of the playability unless you're on some very odd crack. You develop a game that you think will suit the market.
Of course, anyone that's armchair quarterbacking Carmack's choices on development effort at this point is probably not thinking in terms of reality, anyway.
What ISPs are selling is latency. Watch the ads: "the page loads / game plays so fast!"
They're not selling bandwidth, even though that's how they inaccurately measure their latency. If they were, then servers would not be an issue.
All of that is moot, however, since there's simple math here:That is, they are selling a service which costs them a certain amount, and they see some percentage usage. They then charge some rate and the delta between those is the profit margin for them. If you are arguing that they should raise the price and eliminate bandwidth concerns, then that's one thing, but if you are suggesting that they keep prices the same, then clearly they have to control one of usage, cost or margin.
Margins in the ISP business right now aren't spectacular, but they're OK. ISPs certainly aren't looking ot LOWER them, so give up on that point. Then you have usage and cost. The cost is negotiated fairly strongly, but ultimately you have the same argument up-stream with backbones as you have between consumers and their ISPs. Then there's uage. Observe the current trend in attempting to manage usage.
If you really want to be charged for a full 1.5, 3, 5 or whatever you have down, you're going to have to expect that prices will skyrocket! If that's what you want, then what's wrong with tiered service?
From where I stand, the whole argument AGAINST tiered service is that the economies of scale in the averaged cost model favor a single tier of consumer service. Then again, I'm a Speakeasy customer now, so I've essentially opted for tiered service anyway by paying more than your average cable Internet user.
You are missing the point, and for once, I think the MPAA is doing the right thing.
They're not looking for the operation that could be replaced by a guy printing DVDs in his basement. They're looking for the operations that send MILLIONS of DVDs around the world via various shipping services. These folks are the real pirates, and if anyone is actually harming the movie industry through piracy, it is these folks, not the college kid that downloads a shakey hand-cam of MI3.
Now, as for privacy concerns... if you had the illusion that there was privacy with respect to internationally shipped packages, then this bit of cold water to the face is JUST WHAT YOU NEEDED. Internationally shipped packaoges are checked for food items, dangerous materials, drugs, etc, etc. There is NOTHING private about shipping internationally, and has not been for decades.
Applications->Accessories->Text editor; Write script; Save script; Right-click->Properties; Click Permissions tab; turn on execute; Close; Double-click script.
Not everything done through the GUI has to be 100% visual. That's the whole point to combining the metaphors via nautilus scripting and actions, for example.
The point is that when working THROUGH a GUI, you can choose to use a command-line or not as you go, and for the most appropriate jobs.
Here's the part that kills me: open source software got its start by bundling OSS programs with proprietary code. This is the history of BSD (and thus SunOS), the whole GNU toolchain including Emacs and gcc which didn't run on an open source platform until the 90s, X windows (which was mixed with various proprietary software over the years, and has always come out the better for it, or at least unscathed), etc.
Now that there's a working system that can stand on its own, all of a sudden the free software advocates (obviously, not ALL of us) are screaming about how bundling is bad.
Proprietary software and free software, IMHO, should continue to play on equal footing. If we're right about the value of the free software proposition, then we'll find that the proprietary stuff will lose out, but that won't actually happen. There are cases where proprietary software exists because it does not scratch the itch of anyone with the technical expertise or willingness to replace it. In those areas, we'll continue to see thriving closed source code, and that's not a bad thing.
Actually, this isn't the way most moderm microkernels work either. Generally, you talk to a THREAD associated with the driver. This thread adopts the callers slot and priority in the run queue temporarily, and scrutinizes the caller's request (performing roughly the analysis that you suggested, but at the appropriate priority, which might be much lower than some other process that wants the same driver a fraction of a milisecond later).
The request is then either carried out in the handler thread, or passed off to a centralized driver thread after triage.
This *is* more complex (which is Torvalds' point), but it's not horrible. Most of it can be wrapped in macros/templates/whatever and is uniform across all drivers.
I think that Tovalds makes some excellent points, and simplistic arguments like "microkernels are more secure because each part is smaller and simpler," are just that: simplistic. Overly so.
Still, there's value in the microkernel approach, as has been repeatedly shown. I'll remind readers that microkernel's don't all look alike. Most functioning microkernels are hybridized in one way or another with monolithic kernels to achieve usability. In the case of MacOS/X, that involves placing a monolithic kernel on top of the microkernel as a subsystem. In the case of NT/XP/Vista, that involves re-writing the most performance- and security-sensitive subsystems as monolithic subsystems (and, shockingly the NT kernel is about the only place that NT gets security right).
Microkernels are here to stay, as they offer some useful abstractions, but I don't think that they harken the doom of monolithic kernels like Linux. It's just a different approach.
No, the open source effort will fail. That's the bad news. The good news is that the problem will be solved.
The reason that an open source effort will fail is because it's not a software problem. It's a hardware problem. More specifically, it's a problem getting the hardware vendors to support open source products (e.g. OOo on Windows and various ODF-compatible applications under Linux, etc.)
That WILL happen. Once more states, hopefully the U.S. Federal Government, and many foriegn governments start requiring ODF supporting applications, the hardware vendors will want their products to get used, and they will make sure that they work.
Step 1: Move the buyers.
Step 2: Let the vendors follow.
"Those 5 patches sound fairly scary, actually."
/dev/lirc, which is what configure tests for).
You're joking, right? You honestly find those worrysome?
You have a one-character change to playtreeparser.c which, as far as I can tell is a bug fix to user-interface lossage, but worst case scenario displays an error when it should not.
The addition of the string "redhat" (one word change) in configure (sets system_name to Linux).
The removal of a startup status message regarding CPU detection.
Turning on a bi-directional text feature.
Forcing LIRC testing in configure (I assume this is because their build environment might have the LIRC headers and libraries, but no installed
What about those is scary?
The only one that sounded sketchy at first was the parameter type change, but on reviewing that, I see that it's not the TYPE, but the parameter NAMES for readv and writev. My guess is that newer versions of gcc are enforcing matching names if names are used. This is probably something that was fixed in later CVS versions, since I assume the project would now have experience with more modern compiler versions.
All a guess, I admit, but it seems logical.
Still, I'm at a loss. Where's the scary?
Indeed... I had not known that. Well, then I suspect they're dead. I can't imagine them reversing their lot on the basis of the SGI brand alone. Perhaps... but it would be a HUGE longshot. The new CEO is almost certainly there to recoup the value of the assets only.
Which you can see has 3 primary components, the 20060314 CVS source of mplayer and ffmpeg, liveMedia from 2006.03.03, and the "Blue" skin, as modified by 6 tiny patches which:
So, as you can see, the Fedora install is pretty recent and fairly virgin in the sense that it has almost nothing unique about it. Now, I'm not clear on what liveMedia is, and perhaps that's considered ugly, who knows. But there you have the goods. If someone says "I'm running stock FC5+freshrpms, you now know what they're talking about (of course, the tricky part is the build environment which may or may not have been up-to-date with respect to updates when the package was compiled -- I recomend that you suggest to users that they re-build the SRPM in case of doubt, which is FAIRLY easy, at least compared to a CVS build, which most will botch or give up on).
"I've seen many people that, when told they have a hardware problem, respond, indignantly, that no other software has problems, only MPlayer. Then a few weeks later, you'll see a message from the same person, saying their CPU fan was going out, and appologizing..."
And I'm sure I've done something equally dense in the past... we all fall down sometimes. The thing is that I've been using Linux since pre-1.0 and Unix since the 80s, and I've contributed to open source projects many times... still, I find reporting bugs to mplayer to be daunting because of the time that the project requires that I spend in order to tell them about a bug. That means that, unlike say firefox, mplayer is disconnected from the woes of its userbase, and will mainly get bug reports that it is willing to cope with from developers and bleeding-edge users. This skews the feedback, and you develop a view of the user base which is not consistent with reality.
With fewer barriers to that process, you would get more representitive bug reports, and perhaps "I get seg faults all the time" would not come as such a shock.
"MPlayer's aggressive code makes for the perfect test of any compilier... Every other application on the planet can compile perfectly, and yet you'll find bugs with MPlayer. -O3, -march, lots of ASM, 3dNow, SSE, MMX, etc."
Surely. I would say that you're going to run into cache-related, bus-related, graphics-related and instruction-related issues that VERY few other programs will. That makes it all the more important that you understand the user base, work with the distributions and, where
Summary:
* New CEO/CFO
* Major holders (read investors) get to keep their shares, everyone else gets nothing
* They have already reduced their size by $100M, and another $50M is coming (layoffs mostly, I imagine)
* They remain optimistic.
IMHO: They are doomed, but if the new CEO isn't just a "make it worth enough to pay off the debt" sort of guy, they could harvest the value of the Cray and SGI brands and parley them into a major product line once again. It would take the vision of a Steve Jobs type, but it could be done.
A side note. If you want anything in terms of debugging information, and you're in a position to actually move my bug report from Slashdot to something useful, I'd be happy to chat via email. I don't have a good sample video file as yet that isn't 300+MB, but drop me a line any time. I'm ajs at the like-named doamin in the dot-com namespace.
You're getting way too upset about this. Please don't take this personally.
I simply said that mplayer (and gmplayer, as you correctly pointed out) crashes for me constantly, and I'm running a completely stock FC5+freshrpms system (and have had similar problems with every Fedora release I've used mplayer on).
Take that as an attack of some sort if you wish, but the fact of the matter is that the reason that I JUST NOW went to read Slashdot is that mplayer crashed at the end of a video file.
If distributions are breaking your software, you need to find out how and get them to fix it, as it is RUINING your reputation for me and anyone else seeing the same problems. If there's a bug... well, you can figure out where I'm going with that one.
I'll try to narrow it down with a small enough sample file that I can send in a bug report at some point, but hundreds of others MUST be seeing this, as I have nothing unusual in installation (fresh hardware and install circa 2-3 weeks ago).
Side note about gcc 2.96 (which I'm not using, I just get kind of touchy about the anti-2.96 comments because it was a vastly misunderstood release): You're bringing up some ancient history here, and yes, there are still buggy versions of 2.96 around (just as with any software), but they were fixed long, long ago. The only compiler bugs that I know of in CURRENT 2.96 versions are those that are endemic to the version (e.g. platform support issues which were addressed with major changes in 3.1+). If your bug reports are coming in from users who are using older revs, then there are workarounds that you could use to fix these issues, but you sound like someone who's not very interested in supporting 2.96 users, so I would suggest to them that they upgrade to the latest updates from their distribution vendor. The suggesting that there are problems with the latest version on that page you pointed to... well, perhaps there are (I'm sure there are in 3.4 or any random version... I assume about a bug per line of code in any software, and gcc has many lines of code), but unless you can narrow that hypothesis a bit more, no one is going to be able to write a fix.
The page that you linked to has some severe misconceptions about the history. I installed 7.0 the week it came out. I recall exactly what the issues were, and other than a few, very early problems that were mostly fixed by 7.1, and all fixed by 7.3, I've never seen a bug that was UNIQUE to 2.96 and did not show up in 3.0 a short while later. Of course, both 3.0 and 2.96 had problems, as they were major changes to gcc (hence the major revision). I would never suggest that someone use 2.96 if they are starting from scratch since it's so old, but if you're using it in a production environment, it's good enough at this point that updating isn't CRUCIAL.
There's a typo in my post. There's a bit that should read "2.<96 was not an option", but my < got eaten.
You keep harping on things like gcc 2.96... You do realize that that was released NINE releases ago for what is, in name, and in practice, a completely different product, right?
What's more, if you go back and look at the history, the Red Hat team had a lot of problems with the release of 2.96 (which was a Red Hat (well, really, Cygnus) pre-release of the compiler version that they (along with the community) had been developing for several years under the previous name egcs... 2.96 was the re-merging of 2.x and egcs into 3.0, a once-again-standards-compliant C and C++ compiler suite). The thing was, everyone else proceded to have the exact same problems a few months later when gcc 3.0 was officially released. There WERE some compiler bugs in 7.0's gcc 2.96, but they were minor and fixed quickly. The REAL PROBLEM was that gcc 2.96 and thus gcc 3.0 enforced standards that gcc 2.x had always been lax about, and thus many programs needed small fixes in order to compile correctly. Everyone took this as "Red Hat enforcing their world view" until gcc 3.0 came out and everyone found out that it was the entire gcc community enforcing the standards.
2.96 was the only stable compiler for Sparc, Alpha and MIPS under Linux at the time. 2.96 was not an option for that reason, and Red Hat had a scheduled release date to make. They were in a tight spot, and they made, IMHO, the right call. The soon released minor releases of 7.1, 7.2 and 7.3 brought much improved versions of the compiler suite and 2.96 is STILL used in many production environments because of its massive improvements in the implementation of C++ without the later experimental features of the 3.1+ releases. The folks at Cygnus took a huge beating for what was ultimately a very well managed release that caused only minor headaches in reality, and they revitalized the gcc project which had stagnated pre-egcs, due to the political tensions between the C and C++ as well as the Intel and non-Intel worlds.
So, if you're going to tell a user that their problems aren't problems, but rather stupid platform issues that the player can't possibly do anything but seg fault on, you might want to talk about the current day and modern compiler releases, or at least not parrot the bad mythology of a few who have an axe to grind against a company that has done more for open source than any 100 of the axe grinders in question.
"As I said, segfaults are very rare these days. Most of the time segfaults are reported, it's buggy hardware (hot CPU, RAM, videocard, etc.) or a known-buggy version of GCC (2.96, 3.3, etc)."
About half of the time that I hit "stop" and close the player on a valid AVI, it seg faults. If I try to play corrupted AVI files (which it should choke on), it seg faults (which it should not do, as that indicates a failure in bounds checking that could be very dangerous if viewing untrusted content). These are common behaviors on multiple machines, one of which is brand new. I've used FC3, FC4 and FC5 without a change in behavior and I have never compiled a custom version of the player (I've used the Fedora and/or FreshRPMS versions only), and are thus compiled with fairly modern compiler versions (circa the distribution release + updates) and I update on a frequent basis from updates, extras, freshrpms and, where applicable, legacy.
I'm a fairly routine user doing fairly routine things, and a dialog with a "signal 11" error is routine for me. What are the developers doing differently that seg faults are so rare for them? Are they only using carefully crafted test files? Are they running with some special libraries or compiler versions? Is there an unreleased fix?
The good news is that Gnutella continues to run strong. I actively share a few Gigabytes of free content including operating systems, free music, public domain image archives and so on via gtk-gnutella which you can acquire from the sourceforge project pages for the gtk-gnutella project. Open up both TCP and UDP ports inbound for whatever port you choose to operate it on, and it performs at least as well as bittorrent, but with amazingly useful searching and filtering options.
The gtk-gnutella folks (who do an excellent job, but could always use more contributors) spend a fair amount of time working out counters for spamming and poisoning techniques.
Obviously, you're not a fan of Eberron, but I think the setting has promise. It makes several bold moves and at the same time, it retains compatibility with other D&D settings and the system as a whole.
I like the warforged for several reasons:
*They're not just "humans made of metal" (role playing not withstanding)
*They impose unique needs on players
*Their background isn't based on mysterious, powerful "ancients" who are gone now
*They can add as much or as little steampunkishness as you like
The other races are fairly par for the course, but I don't dislike any of them. The fact that some otherwise minor monsters (e.g. Rakshasa) play a major part in the world is nice. The use of dragons was fairly novel, but not overbearing (such as the way they were used in Arcana Evolved, which is a very nice system modification, but sometimes grating as a setting for me).
Overall, it's just a high-magic D&D world like you would expect, and I think it caps off the spectrum nicely when viewed in combination with the other D&D worlds including Greyhawk (I run a game set here), Forgotten Realms (I love the basic concept, but haven't been able to make the time yet to dive in), Dragonlance (not a fan personally, but I know a few people who enjoyed it), Ravenloft (S&S did some good work on this, under their license from WotC), etc.
"This is funny, it almost sounds from the article that they changed their methodology to increase their claimed "losses", and had to rein them back in when they discovered their losses exceeded global Gross (International) Product."
You are failing to comprehend the depth of the crisis! The international economy's shortfall in this respect is costing the movie industry TRILLIONS! If only Turkey had a gross national product of 82 gigabucks, surely half of it would have been spent on copies of movies that people already owned, but had no moral right to either duplicate or simply stop re-watching!
This is a crime, and make no mistake... there is going to be a law! The only realistic solution at this point is to cede control of the World Monetary Fund to the MPAA.
I'm constantly running into segfaults in mplayer. I don't know if it's just a whacky codec or what, but no matter what the input, no player should ever segfault on any media. If it does, that means that memory is being handled poorly, and that's a potential opportunity for an attack vector.