Your general points are worthwhile, but I have some criticisms.
* Your criticisms of businesses in other places, espcially in europe, are primarily in the political domain. You may feel these actions are unethical, but they are not in the domain of _business ethics_. I think the point was that by and large, German companies (possibly other european ones?) have a much stronger sense of the ethics of doing business, that they have a stronger sense of how to act in the marketplace prevails as opposed to the more American "anything goes". This is substantiated, I believe, by the comparitive teeth in the american SEC designed to keep trading regular, wheras in the german stock market, no such strong police agent exists, but the trading remains, by and large, regular.
* SuSE isn't too young to screw up, they've been in business ten years already, and have made various serious errors already. (I could enumerate them, but think using my inside employee information to defame is in poor taste!)
* There's no need to bring up a bunch of hot-button politics in response to a cultural comparison.
1) Try to choose working with as many partners as possible in a spirit of cooperation.
2) Do not reap the PR benefits, nor spin the relationship strongly in the public eye at all.
3) Allow some partner to control the spin to their own agenda (in this case Caldera/SCO).
4) Eventually find that the partner has taken a (to SuSE's viewpoint) incredulous stand. Publically state that they do not agree.
5) Partnership and sails of other company deflate/dissolve.
SuSE is a somewhat naive company in the way it forms alliance, makes choices, etc. They do not believe in strong spin or overbearing marketing. They do not believe in half-truth statements or downplaying their competitors. There may be exceptions to this (there's no single decisionmaker running the whole show), but as a general rule it holds.
When I was there, it was fairly common for them to observe a sharply competitive move and collectively shake their heads. They _do_ believe in making better products, so this kind of competition is welcomed with open arms, but patent lawsuits are viewed in this sort of way I see as typical german: "This is not good."
All in all, I have to say I saw this as the eventual outcome of United Linux. I see SuSE and Connectiva as technology leaders, with Turbo and SCO/Caldera ultimately hamstrung by the strange politics/business of their leadership. The former can make a solid partnership, no doubt, the latter pair do not belong in the same ship.
Re:Noun vs. verb? I think not
on
Netscape 7.0 is Out
·
· Score: 2, Informative
It's true that affect and effect have noun and verb forms each. However, it's also true that 90% of the time, effect is a noun while affect is a verb.
Common usage inclues: What will be the effects of this action? What things will this action affect?
Because they are used in a related context so frequently, it does not surprise me that people have trouble with them, hence the simple rule of thumb: effect == noun, affect == verb.
In truth of course, you can 'effect' to bring into being, and something may have an 'affect', meaning an assumed aspect, perhaps even a pretentious one. In practice, these words are uncommon enough (though not rare) that many people are completely unaware of them.
And probably yes, especially Americans. Our poor schools:-(
The only common thread I've seen regarding Red Hat has been along quality lines.
I am not certain that arguing these particular points is relevant here, but they are generally of a high level decision making nature, more than a low level goof-up nature.
They have gotten minor kickback here and there for making decisions that some people feel are 'loose cannon' type things. Examples include early deployment of glibc 2.0, and the original rollout of "gcc 2.96".
None of this, however, paints them in the light of a controlling "Microsoft" position.
As a strong SuSE partisan, I would be very very happy if my favourite distribution engineers would take a page from Red Hat's book and GPL their extremely effective build system for the benefit of all.
I have no problem with a linux which is not UNIX. Personally I'd love to see a BeOS or AmigaDos on the linux kernel. However, Mandrake goes to the trouble to provide bash and so forth, but their default install won't run a normal unix script. Oops. I consider this deceit of customers, and a burden for developers of Linux apps.
Allocation of 4k chunks was not the problem a broken compiler which could fail for trivial applications was the problem That it doesn't fail for all trivial applications is not terribly redeeming.
Mind you, I didn't suggest shutils was missing from Mandrake, but missing from the default install. "Non-Compliant by default" is right up there with "It works for me" as computer industry wrongthink. Mandrake had a nice shiny checkbox for "shell utilities" which was unchecked by default. Or maybe it was "Command line tools". Imperfect memory.
RPM based distro that ships with KDE? SuSE. You get all that as well as smart developers who know what they're doing. (Of course all distros come with KDE nowadays, but i'm assuming mean as a nicely configured default). Of course it isn't worth reinstalling, learning quirks, but it's worth it to me as a developer to resist new deployment of a system which makes my life harder.
Best wishes with syllable. Anything that explores new ground or even makes a new attempt at familiar ground which is yet to be mastered is an important endeavour in my book.
All of the flaws you highlight (Real or imagined) are an issue with the Mandrake build and test process, and are nothing to do with Mandrake being an easy to use distribution.
I didn't suggest it was hard to use. I suggested it was built with a foolish lack of concern for a great many things that matter besides ease of use. Additionally, these errors end up costing in the realm of fixing/maintaining, which some people might feel is more important to 'ease of use' than the first impressions.
However, that does not make me an idiot, or a clueless user, simply because I choose to use Mandrake.
It doesn't make you an idiot, but it does mean that the distrubution is _designed_ for the lowest common denominator. If I want to be uncharatible, idiots. This mindset of "I just want it to be easy and I don't care if it's poorly designed and unfixable" makes me wonder why Mandrake users don't go use Windows XP. It works decently you know.
Much chatter about install selections elided. Any distribution which doesn't make this simple is broken.
Huge sections of the POSIX shell environment are missing.
Which sections? I have not noticed any differences between Mandrake 8.0 and Redhat. I have not seen any missing tools. Also, which POSIX standard are you refering too? My copy of POSIX Programmers Guide only shows P1003.2 (Definition of a standard command shell language) as "in progress". Admitedly, the list was compiled in 1993, but I'm not aware of any official POSIX standard that defines the shell?
Please review POSIX 1003.2. Mandrake leaves out many of the required shell utilities by default. As a result, posix compliant shell scripts will not run on Mandrake. I don't remember the exact list. I seem to remember that shutils was simply not available. Yes. Really. NO SHUTILS.
a compiler which produced segfaulting executables with the most trivial code, such as a C program which simply allocated memory in a while(1) loop.
I'm not aware of these issues with gcc-2.96 (The version I have here, in Mandrake 8.0). I've tried a simple application, as you outline* and I see no segfault. Naturally, leaving a malloc(); inside of a while(1) loop will eventually cause undesirable behaviour, but you can't blame the compiler for that.
In the context in question, I wanted to ensure that I could allocate all the memory on the machine without it falling over. This was a controlled stress test to push the VM, ensure proper memory detection, and the memory/disk subsystems. These were real points of failure at the time (2.2.17 and so on).
I had other programs which nicelay allocated and deallocated memory willy nilly with walking ones and zeros patterns while this program would simply allocate memory until it was given an error or until it was killed by the OOM killer. It wasn't guilty of causing overcommits at all. It dutifully touched each page as it was allocated, so no problem there.
I had various problems with the various tests, but finally was able to get the allocator to die in some cases on its own, which was allocating memory in 4096 byte chunks. This was shocking to me. Copying over the red-hat compiled binary of the same error produced no errors at all.
Please note, additionally, that there is no gcc 2.96. It is a fiction. Red Hat lifted a pre-release of 2.96 from the gcc cvs tree and called it gcc 2.96. The GCC developers had no intention of anyone considering this an actual version or release, it was just the version they would have used had they finished with the release. Because of this problem, 2.96 was marked as a banned never-release version of gcc which would not see the light of day to avoid confusion with the Red Hat release.
Thus, there was no gcc-2.96, but merely a CVS snapshot with a TON of important patches. It would be more appropriate to call it gcc-2.9redhat. Mandrake's version, with less expertise was far more flawed and problemed. For all I know they released repatched versions later, but simply that they distribute 2.96 shows they are either passing along Red Hat's questionable decision or continuing to be even more misleading to their users by producing a second build of gcc which also is not gcc 2.96, but is not the same build as Red Hat's.
As for documentation, I have the man pages & google. Not to mention, I've done most of it plenty of times before:)
Man pages and Google are great. Info pages are even better (if you hate them, learn to use pinfo or the KDE info viewer, or something.
But if a distribution vendor provides a piece of software specific to their own distribution, the onus is on THEM to document it, in a man page, in an info page, in a textfile, somewhere. Mandrake has failed to provide one drop of documentation for some of their programs. The mentality is: this is a program which sits behind a gui program, no one needs to know anything about it. This way leads to madness.
Mind you, I didn't even get into the cheap shots, like the corrupting fonts in 7.2 and the blind slipstream rpm 4.x release and etc. etc. etc.
Mandrake does not comprehend the UNIX way. Those who do not understand the mistakes of the past are busy repeating them and all that.
Why is it that people must label Mandrake as some sort of "Linux for idiots" distribution?
Because it is.
Mandrake upon a default install does not provide a valid UNIX installation. Huge sections of the POSIX shell environment are missing.
Mandrake tends to build their own tools the nice unix way, with a backend engine, and a frontend GUI. However, they forget to document the backend in any sort of reasonable way, and generally assume all users will only ever want to use the GUI. Example in the 8.0 days was the upgrading tool, which talked to a backend, which talked to urpmi. There was no documentation on this backend tool in any part of the distribution, on any part of their web site, or on any developer pages I could find. When the backend was crashing for me, I had to use gdb and strace to simply FIND OUT WHAT IT WAS DOING. I then decided it might be falling down over strange return values from urpmi, and wiped out the relevant part of urpmi's database in order to get the whole thing working again. Note the top level error of the gui tool exposed to the user was: An error has occurred.
Mandrake follows the Red Hat practice of delivering alpha and beta quality software releases out of CVS trees but lacks Red Hat's technical excellence to reduce the fatal flaws. Mandrake followed Red Hat's lead with gcc "2.96" but provided a compiler which produced segfaulting executables with the most trivial code, such as a C program which simply allocated memory in a while(1) loop.
Similarly, when Red Hat included the not-yet-beta vim 6.0 with all the features turned off to make it safe (why use the new vim when you have to disable all the new features?), Mandrake pulled in vim 6.0 but left many features on, leading to the editor croaking on me at very inconvenient times.
Mandrake has _terrible_ documentation. Prior to mandrake 8.1 there were no published software flaws at all! The bug database is very sparsely populated. The manual is fluff and the online support generally focuses on trivial basics with a real lack of information on mandrake-specific tools in detail. If you write a tool for your own distribution, you need to document it. This is worse than the KDE team and KWin here.
When attempting to test the compatability of different linux distributions across a range of supplied hardware (I was working for a vendor at the time) Mandrake was unable to handle more than 1.5 GB of ram without crashing and burning. The install didn't even suggest there might be an issue, it would just fall over now and then. After spending an hour or so finding their bug database, I logged the problem, and a day or two later it was followed up with a suggestion to try the 'enterprise' kernel. That sounds great. Where is the 'enterprise' kernel? It was in no docs, in no install selection, and I couldn't find a file containing the string 'enterprise' on the CD images. Requests for further information turned up silence.
The Mandrake development team is exceedingly haphazard. They make tools where ones already exist (see package maintenance above, why not use connectiva's apt?) and have fail to understand their role in software very well. On problems specific to mandrake but even more so on 'personal' side projects run by Mandrake employees (eg. Frozen Bubble) I've received the worst kind of developer bad attitude. Examples include:
Refusal to believe a bug happened when all necessary information to reproduce the bug is included with the bug report. "Cannot reproduce" I can accept, but not "I refuse to believe that happened. end of discussion"
Declaration that because a bug does not manifest on the developer system, it does not exist.
Insane statements that because the developer is a free software author and spends his/her time to make software for me, I should have no expectations that they look at my bug reports. Hello, I am a free software author spending my time to help make your software better, and have an expectation that they either maintain or abdicate maintenance of their software, not make strange moralistic claims about bug reports being wastes of their time.
Mandrake has come out and publically declared that there is no need for them to support Linux compatability efforst because they are already compatable (with Red Hat). Nevermind that they (as above) do a poor job of chasing Red Hat, the LSB fundamentally extends the benefits of the Linux/Free Software world by providing clarity as a software creator as to whether a binary problem lies in the application or operating system domain. Thus, it provides additional rights to the users of the system, and an ability to clearly identify and fix bugs in the vendor's provided distribution. How can you not see the benefit here?
In short, Mandrake does indeed have a pretty gui, so if that's all you care about, you could choose Mandrake, or SuSE really, or just install Ximian Gnome on whatever. But if you care about stability, or the documentation and solvability of your system, or UNIX compatability, or Linux compatability, or quality of supplied software, or software freedom.. then there's really no good reason to use Mandrake.
1) Make your repository a mountable file system, supporting multiple types of connection, NFS, SMB, Active Directory, FTP, etc.. When connecting you must specify a profile to be used.
Filesystem semantics are not version control semantics. The semantics of all those filesystems and things are very different. Using a filesystem access method to get to the version control system intoroduces significant operating system reliance and issues.
In general, this approach will complicate the server, complicate the client, introduce subtle consistency and corruption issues acrosss access methods, and offer no significant features that a local working set offers. In addition, most operations will be slower than a local set.
2) Make every user have a number of profiles (Min:1) (like ClearCase views), these profiles contain -all- the info needed to access file versions correctly. They should allow sharing ('base my profile X on the profile Y created by user Z'). And support concepts such as labelling, conditional branching, etc..
And _why_ do you need per-user views of the world? Can't the users figure out what files they want?
In the smaller company/project case, you need a single view of the world that every single person sees. If they want to access older versions of things or other branches, they can all explicitly use the same controls to go see those things.
In the larger company case, you may have specific lines of development, branches, and/or takes on the source base which relate to projects or reconfigurations of the sourcebase. Here you can set up views of the world which exist independent of the users, are created once and are consistent across all people who want to view the system in that way.
The clearcase system of many views of the world per individual user leads to mass confusion and horror as no one knows what anyone is doing, everything is out of sync, and people copy increasingly broken configurations one to the next in a whisper-down-the-lane scenario from hell. This doesn't even require a poorly managed or large engineering team to do it. 50 developers or so working in the same arena and you've already lost.
3) All profiles are managed from a central server (redundancy?) via a web interface (to achive cross-platform conformity) and command-line interface (SSH based) for scripting/power-users.
Central server required. Great. No disconnected operation. No multiple office/continent/timezone, etc. development without huge costs. No realistic open source development model flexibility.
Do we really need MORE indications that ClearCase is not a fundamentally workable tool?
Just say "No" to ClearCase!
Brought to you by the Campaign for Sanity for Developers.
Making a chip radiation hardened is a big engineering undertaking, for a lot of reasons. The indivudual chips are very expensive, and thus the testing cycles are expensive. The testing process is long, and the skills to make it work is uncommon. Radition hardening a "simple" microprocessor like a 386 or a sparc might cost in the hundreds of millions, while a processor like a p4 would probably not even be considered.
Nasa may move to the original pentium as a control center chip in the near future, as Intel so graciously donated their pentium design for this purose (a small fraction of the cost of the actual radiation hardening design work!) Last I checked it was still rs6000 processors for system control with 8086's for simpler tasks.
O.K, I shall admit that the "My Music" editor does take some getting used to. I personally blame this on the craptacular playlist mangement that is present in WinAMP & XMMS, however. If you say the UI in FreeAMP is bad, what the heck are those silly little TLA labelled buttons in the WinAMP playlist "Manager"? Ick!
Yes, the winamp/xmms idea of what to name buttons etc is stupid, but it does let me straightforwardly add, remove relocate items in a playlist. More to the point I can add an album to my playlist like this:
xmms Mu[TAB]mp[TAB]c[TAB]St[TAB]Sou[TAB][ENTER]
At this point every track in Sting's "Soul Cages" is added to my playlist. And faster than I could even FIND the retarded window for either player.
Add onto this that i have music in over 20 formats, then the whole stupidity of FreeAmp arrogantly assuming I want to make it the CENTER of my music playing world becomes apparent.
I enqueue my music with custom python scripts because all the players are too stupid to provide any sophisticated features. Moreover, if i could reliably get them to exit and/or signal a master script when they finished a song, i wouldn't NEED a 'player' program at all, but simply commandline tools that take a single file argument, play it, and exit.
COME ON PEOPLE! Don't we remember the lessons UNIX taught us? Decouple unrelated functionaltity! Make things simple and interoperable! Don't make bloated incompredensible unscriptable nightmares!
UnitedLinux is clearly an attempt to raise the commercial value of compatible and LSB-compliant linux distributions.
The Mandrake solution of 'blindly do whatever RedHat does' does make things somewhat compatable, but there are a lot of drawbacks to this strategy, and it doesn't really help the commercial software vendors at all if Red Hat decides to change what they provide from version to version. (And they do.)
The Linux Standard Base is useful, it is relevant, it is important. This draws attention to and raises the bar of interest in this regard.
Now, please explain, all you slashbots, how this is a bad thing?
...it says that a network connection is only required when a full save is required - it caches what the user is doing.
There's no possible way to do that. How much logic is running on Word in between saves? Is your PDA going to run real-time grammar and spelling checks as you type, all locally?
On the contrary, windows filesharing gives you this "for free". On a real windows box, an open file is often 'owned' by the client due to a SMB optlock, or opportunistic lock. Piddly reads and writes to the file are cached to the client, and the entire summation of changes is sent back to the server when the file is closed, or the lock broken by the server, or on some other such event. This allows the terrible terrible code of MSOffice to still have some level of performance. It's actually a very powerful (and somewhat dangerous) performance feature, the best part of SMB really.
It could be that these folks are trying to talk about something else, but claiming their words aren't possible is silly as every windows client does this.
Hah, I'm _still_ boycotting blizzard over their complete disregard for privacy and malware concerns over the starcraft name emailing debacle.
The big deal there was not so much that they erred, or that they shipped such an egrious piece of software that would pass your personal registry items to blizarred if you miskeyed your registration code, but that they refused to admit that there was anything questionable about this or that there was any other angle from which to view the situation.
A company that effectively implants spyware in their product and refuses to accept that this was an undesirable action is untrustworthy and is not a reasonable source of software products. At least, that's my view.
The poster explicity mentioned the existence of a seperate collate and merge stage.
Re:'The Economist' is guilty of wishful thinking
on
Andreesen "Grows Up"
·
· Score: 1
You dropped the Economist because it's tech reporting wasn't up to snuff? Next you'll give up watching Baywatch because the plots are weak.
No, I dropped the Economist for many reasons, but among them they devoted a large portion of one issue to matters where they proved unable to check their conclusions in a reasonable manner. Combined with lack of time to read it, and a growing disinterest in politics at the time, this lack of competency at verifying stance on a multi-article big splash magazine focus was the straw which broke the camel's back.
Re:'The Economist' is guilty of wishful thinking
on
Andreesen "Grows Up"
·
· Score: 2
The Economist is generally a well researched and rather insightful magazine which mostly covers political, financial, and business news on a global scale. Unfortunately, their technology research and reporting leaves something to be desired.
This is the magazine which tried to compare the advent of multimedia with the occurence of the personal computer, claiming it was a similar level of transition, and that it could unseat microsoft and make them irrelevant etc. This was in 1994, when it had already become clear to many that multimedia was overhyped and not going to hold any real importance in overall computing. It's one of the reasons I dropped my subscription, as it seemed so clearly ill-reserached and considered.
All in all, take tech reporting from the big E with a grain of salt.
Slashdot Mirror
Your general points are worthwhile, but I have some criticisms.
* Your criticisms of businesses in other places, espcially in europe, are primarily in the political domain. You may feel these actions are unethical, but they are not in the domain of _business ethics_. I think the point was that by and large, German companies (possibly other european ones?) have a much stronger sense of the ethics of doing business, that they have a stronger sense of how to act in the marketplace prevails as opposed to the more American "anything goes". This is substantiated, I believe, by the comparitive teeth in the american SEC designed to keep trading regular, wheras in the german stock market, no such strong police agent exists, but the trading remains, by and large, regular.
* SuSE isn't too young to screw up, they've been in business ten years already, and have made various serious errors already. (I could enumerate them, but think using my inside employee information to defame is in poor taste!)
* There's no need to bring up a bunch of hot-button politics in response to a cultural comparison.
1) Try to choose working with as many partners as possible in a spirit of cooperation.
2) Do not reap the PR benefits, nor spin the relationship strongly in the public eye at all.
3) Allow some partner to control the spin to their own agenda (in this case Caldera/SCO).
4) Eventually find that the partner has taken a (to SuSE's viewpoint) incredulous stand. Publically state that they do not agree.
5) Partnership and sails of other company deflate/dissolve.
SuSE is a somewhat naive company in the way it forms alliance, makes choices, etc. They do not believe in strong spin or overbearing marketing. They do not believe in half-truth statements or downplaying their competitors. There may be exceptions to this (there's no single decisionmaker running the whole show), but as a general rule it holds.
When I was there, it was fairly common for them to observe a sharply competitive move and collectively shake their heads. They _do_ believe in making better products, so this kind of competition is welcomed with open arms, but patent lawsuits are viewed in this sort of way I see as typical german: "This is not good."
All in all, I have to say I saw this as the eventual outcome of United Linux. I see SuSE and Connectiva as technology leaders, with Turbo and SCO/Caldera ultimately hamstrung by the strange politics/business of their leadership. The former can make a solid partnership, no doubt, the latter pair do not belong in the same ship.
Blah. blah. blah.
I've never seen a real elf before either, but they did a fine job there.
Gollum was fairly distracting, not only for the CG but also for the completely over-the-top cinematography and effects used to present him.
Chess:
8x8 board
64 locations, 13 piece types of 2 colors.
Locations can be filled or blank.
27 ^ 64
>>> 27 ** 64
404837660228432814111844721895716547522075068
820903057422001161010657660267188207581747750
41
Go:
19 x 19 board
361 locations, 1 piece types of 2 colors.
Locations can be filled or blank.
3 ^ 361
>>> 3 ** 361
1740896506590319279071882380705643679466027249
5026354119482811870680105167618464984116279288
9887149386120969888163207806137549871813550931
29514803369660572893075468180597603
Diab?
It's true that affect and effect have noun and verb forms each. However, it's also true that 90% of the time, effect is a noun while affect is a verb.
Common usage inclues:
What will be the effects of this action?
What things will this action affect?
Because they are used in a related context so frequently, it does not surprise me that people have trouble with them, hence the simple rule of thumb: effect == noun, affect == verb.
In truth of course, you can 'effect' to bring into being, and something may have an 'affect', meaning an assumed aspect, perhaps even a pretentious one. In practice, these words are uncommon enough (though not rare) that many people are completely unaware of them.
And probably yes, especially Americans. Our poor schools :-(
The only common thread I've seen regarding Red Hat has been along quality lines.
I am not certain that arguing these particular points is relevant here, but they are generally of a high level decision making nature, more than a low level goof-up nature.
They have gotten minor kickback here and there for making decisions that some people feel are 'loose cannon' type things. Examples include early deployment of glibc 2.0, and the original rollout of "gcc 2.96".
None of this, however, paints them in the light of a controlling "Microsoft" position.
As a strong SuSE partisan, I would be very very happy if my favourite distribution engineers would take a page from Red Hat's book and GPL their extremely effective build system for the benefit of all.
I have no problem with a linux which is not UNIX. Personally I'd love to see a BeOS or AmigaDos on the linux kernel. However, Mandrake goes to the trouble to provide bash and so forth, but their default install won't run a normal unix script. Oops. I consider this deceit of customers, and a burden for developers of Linux apps.
Allocation of 4k chunks was not the problem a broken compiler which could fail for trivial applications was the problem That it doesn't fail for all trivial applications is not terribly redeeming.
Mind you, I didn't suggest shutils was missing from Mandrake, but missing from the default install. "Non-Compliant by default" is right up there with "It works for me" as computer industry wrongthink. Mandrake had a nice shiny checkbox for "shell utilities" which was unchecked by default. Or maybe it was "Command line tools". Imperfect memory.
RPM based distro that ships with KDE? SuSE. You get all that as well as smart developers who know what they're doing. (Of course all distros come with KDE nowadays, but i'm assuming mean as a nicely configured default). Of course it isn't worth reinstalling, learning quirks, but it's worth it to me as a developer to resist new deployment of a system which makes my life harder.
Best wishes with syllable. Anything that explores new ground or even makes a new attempt at familiar ground which is yet to be mastered is an important endeavour in my book.
Guy, I'm not some longtime bitter and frustrated user of Mandrake.
I used Mandrake for work for about 3 weeks in order to validate it on a line of hardware. I was pretty shocked that it was that bad.
94-97 Slackware. 97-2002 SuSE. 2002 Debian.
Oh, and how did your program exit?
All of the flaws you highlight (Real or imagined) are an issue with the Mandrake build and test process, and are nothing to do with Mandrake being an easy to use distribution.
I didn't suggest it was hard to use. I suggested it was built with a foolish lack of concern for a great many things that matter besides ease of use. Additionally, these errors end up costing in the realm of fixing/maintaining, which some people might feel is more important to 'ease of use' than the first impressions.
However, that does not make me an idiot, or a clueless user, simply because I choose to use Mandrake.
It doesn't make you an idiot, but it does mean that the distrubution is _designed_ for the lowest common denominator. If I want to be uncharatible, idiots. This mindset of "I just want it to be easy and I don't care if it's poorly designed and unfixable" makes me wonder why Mandrake users don't go use Windows XP. It works decently you know.
Much chatter about install selections elided. Any distribution which doesn't make this simple is broken.
Which sections? I have not noticed any differences between Mandrake 8.0 and Redhat. I have not seen any missing tools. Also, which POSIX standard are you refering too? My copy of POSIX Programmers Guide only shows P1003.2 (Definition of a standard command shell language) as "in progress". Admitedly, the list was compiled in 1993, but I'm not aware of any official POSIX standard that defines the shell?
Please review POSIX 1003.2. Mandrake leaves out many of the required shell utilities by default. As a result, posix compliant shell scripts will not run on Mandrake. I don't remember the exact list. I seem to remember that shutils was simply not available. Yes. Really. NO SHUTILS.
I'm not aware of these issues with gcc-2.96 (The version I have here, in Mandrake 8.0). I've tried a simple application, as you outline* and I see no segfault. Naturally, leaving a malloc(); inside of a while(1) loop will eventually cause undesirable behaviour, but you can't blame the compiler for that.
In the context in question, I wanted to ensure that I could allocate all the memory on the machine without it falling over. This was a controlled stress test to push the VM, ensure proper memory detection, and the memory/disk subsystems. These were real points of failure at the time (2.2.17 and so on).
I had other programs which nicelay allocated and deallocated memory willy nilly with walking ones and zeros patterns while this program would simply allocate memory until it was given an error or until it was killed by the OOM killer. It wasn't guilty of causing overcommits at all. It dutifully touched each page as it was allocated, so no problem there.
I had various problems with the various tests, but finally was able to get the allocator to die in some cases on its own, which was allocating memory in 4096 byte chunks. This was shocking to me. Copying over the red-hat compiled binary of the same error produced no errors at all.
Please note, additionally, that there is no gcc 2.96. It is a fiction. Red Hat lifted a pre-release of 2.96 from the gcc cvs tree and called it gcc 2.96. The GCC developers had no intention of anyone considering this an actual version or release, it was just the version they would have used had they finished with the release. Because of this problem, 2.96 was marked as a banned never-release version of gcc which would not see the light of day to avoid confusion with the Red Hat release.
Thus, there was no gcc-2.96, but merely a CVS snapshot with a TON of important patches. It would be more appropriate to call it gcc-2.9redhat. Mandrake's version, with less expertise was far more flawed and problemed. For all I know they released repatched versions later, but simply that they distribute 2.96 shows they are either passing along Red Hat's questionable decision or continuing to be even more misleading to their users by producing a second build of gcc which also is not gcc 2.96, but is not the same build as Red Hat's.
As for documentation, I have the man pages & google. Not to mention, I've done most of it plenty of times before :)
Man pages and Google are great. Info pages are even better (if you hate them, learn to use pinfo or the KDE info viewer, or something.
But if a distribution vendor provides a piece of software specific to their own distribution, the onus is on THEM to document it, in a man page, in an info page, in a textfile, somewhere. Mandrake has failed to provide one drop of documentation for some of their programs. The mentality is: this is a program which sits behind a gui program, no one needs to know anything about it. This way leads to madness.
Mind you, I didn't even get into the cheap shots, like the corrupting fonts in 7.2 and the blind slipstream rpm 4.x release and etc. etc. etc.
Mandrake does not comprehend the UNIX way. Those who do not understand the mistakes of the past are busy repeating them and all that.
Because it is.
Mandrake upon a default install does not provide a valid UNIX installation. Huge sections of the POSIX shell environment are missing.
Mandrake tends to build their own tools the nice unix way, with a backend engine, and a frontend GUI. However, they forget to document the backend in any sort of reasonable way, and generally assume all users will only ever want to use the GUI. Example in the 8.0 days was the upgrading tool, which talked to a backend, which talked to urpmi. There was no documentation on this backend tool in any part of the distribution, on any part of their web site, or on any developer pages I could find. When the backend was crashing for me, I had to use gdb and strace to simply FIND OUT WHAT IT WAS DOING. I then decided it might be falling down over strange return values from urpmi, and wiped out the relevant part of urpmi's database in order to get the whole thing working again. Note the top level error of the gui tool exposed to the user was: An error has occurred.
Mandrake follows the Red Hat practice of delivering alpha and beta quality software releases out of CVS trees but lacks Red Hat's technical excellence to reduce the fatal flaws. Mandrake followed Red Hat's lead with gcc "2.96" but provided a compiler which produced segfaulting executables with the most trivial code, such as a C program which simply allocated memory in a while(1) loop.
Similarly, when Red Hat included the not-yet-beta vim 6.0 with all the features turned off to make it safe (why use the new vim when you have to disable all the new features?), Mandrake pulled in vim 6.0 but left many features on, leading to the editor croaking on me at very inconvenient times.
Mandrake has _terrible_ documentation. Prior to mandrake 8.1 there were no published software flaws at all! The bug database is very sparsely populated. The manual is fluff and the online support generally focuses on trivial basics with a real lack of information on mandrake-specific tools in detail. If you write a tool for your own distribution, you need to document it. This is worse than the KDE team and KWin here.
When attempting to test the compatability of different linux distributions across a range of supplied hardware (I was working for a vendor at the time) Mandrake was unable to handle more than 1.5 GB of ram without crashing and burning. The install didn't even suggest there might be an issue, it would just fall over now and then. After spending an hour or so finding their bug database, I logged the problem, and a day or two later it was followed up with a suggestion to try the 'enterprise' kernel. That sounds great. Where is the 'enterprise' kernel? It was in no docs, in no install selection, and I couldn't find a file containing the string 'enterprise' on the CD images. Requests for further information turned up silence.
The Mandrake development team is exceedingly haphazard. They make tools where ones already exist (see package maintenance above, why not use connectiva's apt?) and have fail to understand their role in software very well. On problems specific to mandrake but even more so on 'personal' side projects run by Mandrake employees (eg. Frozen Bubble) I've received the worst kind of developer bad attitude. Examples include:
"Cannot reproduce" I can accept, but not "I refuse to believe that happened. end of discussion"
Mandrake has come out and publically declared that there is no need for them to support Linux compatability efforst because they are already compatable (with Red Hat). Nevermind that they (as above) do a poor job of chasing Red Hat, the LSB fundamentally extends the benefits of the Linux/Free Software world by providing clarity as a software creator as to whether a binary problem lies in the application or operating system domain. Thus, it provides additional rights to the users of the system, and an ability to clearly identify and fix bugs in the vendor's provided distribution. How can you not see the benefit here?
In short, Mandrake does indeed have a pretty gui, so if that's all you care about, you could choose Mandrake, or SuSE really, or just install Ximian Gnome on whatever. But if you care about stability, or the documentation and solvability of your system, or UNIX compatability, or Linux compatability, or quality of supplied software, or software freedom.. then there's really no good reason to use Mandrake.
Ugh, as expected, you're wrong on all points.
1) Make your repository a mountable file system, supporting multiple types of connection, NFS, SMB, Active Directory, FTP, etc.. When connecting you must specify a profile to be used.
Filesystem semantics are not version control semantics. The semantics of all those filesystems and things are very different. Using a filesystem access method to get to the version control system intoroduces significant operating system reliance and issues.
In general, this approach will complicate the server, complicate the client, introduce subtle consistency and corruption issues acrosss access methods, and offer no significant features that a local working set offers. In addition, most operations will be slower than a local set.
2) Make every user have a number of profiles (Min:1) (like ClearCase views), these profiles contain -all- the info needed to access file versions correctly. They should allow sharing ('base my profile X on the profile Y created by user Z'). And support concepts such as labelling, conditional branching, etc..
And _why_ do you need per-user views of the world? Can't the users figure out what files they want?
In the smaller company/project case, you need a single view of the world that every single person sees. If they want to access older versions of things or other branches, they can all explicitly use the same controls to go see those things.
In the larger company case, you may have specific lines of development, branches, and/or takes on the source base which relate to projects or reconfigurations of the sourcebase. Here you can set up views of the world which exist independent of the users, are created once and are consistent across all people who want to view the system in that way.
The clearcase system of many views of the world per individual user leads to mass confusion and horror as no one knows what anyone is doing, everything is out of sync, and people copy increasingly broken configurations one to the next in a whisper-down-the-lane scenario from hell. This doesn't even require a poorly managed or large engineering team to do it. 50 developers or so working in the same arena and you've already lost.
3) All profiles are managed from a central server (redundancy?) via a web interface (to achive cross-platform conformity) and command-line interface (SSH based) for scripting/power-users.
Central server required. Great. No disconnected operation. No multiple office/continent/timezone, etc. development without huge costs. No realistic open source development model flexibility.
Do we really need MORE indications that ClearCase is not a fundamentally workable tool?
Just say "No" to ClearCase!
Brought to you by the Campaign for Sanity for Developers.
Yup, it's radiation hardening that's the issue.
Making a chip radiation hardened is a big engineering undertaking, for a lot of reasons. The indivudual chips are very expensive, and thus the testing cycles are expensive. The testing process is long, and the skills to make it work is uncommon. Radition hardening a "simple" microprocessor like a 386 or a sparc might cost in the hundreds of millions, while a processor like a p4 would probably not even be considered.
Nasa may move to the original pentium as a control center chip in the near future, as Intel so graciously donated their pentium design for this purose (a small fraction of the cost of the actual radiation hardening design work!) Last I checked it was still rs6000 processors for system control with 8086's for simpler tasks.
Yes, the winamp/xmms idea of what to name buttons etc is stupid, but it does let me straightforwardly add, remove relocate items in a playlist. More to the point I can add an album to my playlist like this:
xmms Mu[TAB]mp[TAB]c[TAB]St[TAB]Sou[TAB][ENTER]At this point every track in Sting's "Soul Cages" is added to my playlist. And faster than I could even FIND the retarded window for either player.
Add onto this that i have music in over 20 formats, then the whole stupidity of FreeAmp arrogantly assuming I want to make it the CENTER of my music playing world becomes apparent.
I enqueue my music with custom python scripts because all the players are too stupid to provide any sophisticated features. Moreover, if i could reliably get them to exit and/or signal a master script when they finished a song, i wouldn't NEED a 'player' program at all, but simply commandline tools that take a single file argument, play it, and exit.
COME ON PEOPLE! Don't we remember the lessons UNIX taught us? Decouple unrelated functionaltity! Make things simple and interoperable! Don't make bloated incompredensible unscriptable nightmares!
UnitedLinux is clearly an attempt to raise the commercial value of compatible and LSB-compliant linux distributions.
The Mandrake solution of 'blindly do whatever RedHat does' does make things somewhat compatable, but there are a lot of drawbacks to this strategy, and it doesn't really help the commercial software vendors at all if Red Hat decides to change what they provide from version to version. (And they do.)
The Linux Standard Base is useful, it is relevant, it is important. This draws attention to and raises the bar of interest in this regard.
Now, please explain, all you slashbots, how this is a bad thing?
There's no possible way to do that. How much logic is running on Word in between saves? Is your PDA going to run real-time grammar and spelling checks as you type, all locally?
On the contrary, windows filesharing gives you this "for free". On a real windows box, an open file is often 'owned' by the client due to a SMB optlock, or opportunistic lock. Piddly reads and writes to the file are cached to the client, and the entire summation of changes is sent back to the server when the file is closed, or the lock broken by the server, or on some other such event. This allows the terrible terrible code of MSOffice to still have some level of performance. It's actually a very powerful (and somewhat dangerous) performance feature, the best part of SMB really.
It could be that these folks are trying to talk about something else, but claiming their words aren't possible is silly as every windows client does this.
Hah, I'm _still_ boycotting blizzard over their complete disregard for privacy and malware concerns over the starcraft name emailing debacle.
The big deal there was not so much that they erred, or that they shipped such an egrious piece of software that would pass your personal registry items to blizarred if you miskeyed your registration code, but that they refused to admit that there was anything questionable about this or that there was any other angle from which to view the situation.
A company that effectively implants spyware in their product and refuses to accept that this was an undesirable action is untrustworthy and is not a reasonable source of software products. At least, that's my view.
Blissfully, I use a digital soundcard.
All that horrific noise is a thing of the past!
Try 'loses'.
Read the post?
The poster explicity mentioned the existence of a seperate collate and merge stage.
No, I dropped the Economist for many reasons, but among them they devoted a large portion of one issue to matters where they proved unable to check their conclusions in a reasonable manner. Combined with lack of time to read it, and a growing disinterest in politics at the time, this lack of competency at verifying stance on a multi-article big splash magazine focus was the straw which broke the camel's back.
The Economist is generally a well researched and rather insightful magazine which mostly covers political, financial, and business news on a global scale. Unfortunately, their technology research and reporting leaves something to be desired.
This is the magazine which tried to compare the advent of multimedia with the occurence of the personal computer, claiming it was a similar level of transition, and that it could unseat microsoft and make them irrelevant etc. This was in 1994, when it had already become clear to many that multimedia was overhyped and not going to hold any real importance in overall computing. It's one of the reasons I dropped my subscription, as it seemed so clearly ill-reserached and considered.
All in all, take tech reporting from the big E with a grain of salt.
yeah, but you lose all the static analysis
possibilities.
-josh