Flamebait perhaps, but not Off Topic. Integrated crypto is a significant feature of OpenBSD. Now Debian has the capability to integrate their crypto. This will propel Debian forward significantly into areas where OpenBSD was once undisputedly the better choice. Perhaps instead of ignorantly moderating, you could have actually posted a response. Of course, that assumes that you are capable of intelligent communication. My bad.
BeOS was always an Operating System vendor. They set out to prove that modern technology could make an elegant system without archaic cruft. They proved it to me... a Mac 7600 running at 120 MHz was hardly a media powerhouse. Running one movie was pretty stressful, don't even joke about running two movies at one time! And then load the BeOS onto the very same hardware, suddenly you can run 6 movies at once, and the little Mac is still fully responsive.
Some of the primary technologies, multithreaded multitasking etc. were intended to leverage the cost effective power available with multiple cheap CPUs running in SMP. For the price of one 200 MHz CPU, you could have bought two 133 MHz CPUs instead, and still saved money. Because SMP machines weren't common at the time, Be developed a box which ran on the Hobbit CPU, because they were the cheapest CPUs available. Later they ported to the Motorola 603, which was also very cheap any very plentiful. Even though the 603 wan't intended for SMP (as was the 604), it was so cheap in comparison that it was still worthwhile to make a custom 603 SMP box instead.
Now that is where your 1st point is off the mark. After supporting the PPC architecture, Mac PPCs were a trivial addition which were worthwhile because they were a relative commodity item. After BeBoxen were no longer cheaper than Macs, the BeBox was discontinues. All along, Be was a modern OS. With the Mac embracement, they started to pla on the "Media OS" angle, but that isn't quite as drastic a shift as your story tells.
Now maybe it wasn't illegal, but it was a monopoly which arguably killed the BeOS. Apple under Gil Amelio was so hospitable (With the clones and such) that Be was lured onto their platform. Then with the return of Jobs, that platform was pulled out from under them. Be was already working on their Intel version, but IMHO the switch was definitely premature, and I was definitely saddened by the sadist returning to Apple, destroying all of the cool things I loved (BeOS, Power Computing...) and having the nerve to claim that I would have just bought an Overpriced Underpowered Apple anyway in a mass mailing I recieved.
Of course, being Commanded from the once Open Apple, they were forced onto the ocean of the Intel world. The dread Pirate Microsoft ruled those waters with impunity, using whatever ruthless tactics they could get away with. Be tried to defer, and claimed to only be a "Media OS" for niche purposes, and not an outright "general purpose" competetor to Windows, even if they were fully capable of it. During yet another Wintel Spat, Intel poured lots of support into Be, making MS jealous, and dooming Be off of the general desktop platform, into the reclusion of the BE-IA space. Of course Microsoft used its Monopoly to illegally bully hardware vendors into being MS exclusive. If they tried to offer a Windows Alternative, they would have had to cough up all of thier lunch money to Microsoft for the privilegde of selling Windows on any of their systems. If they were exclusive with Windows, then the rates were much reduced.
There were many reasons why Be didn't make it. But your alleged lack of focus was merely a symptom of the problem. All along, Be was focused on supporting and promoting the BeOS, thier "fully modern Operating System." Everything else was incidental.
-castlan
Re:A good UI is only as good as the apps
on
BeOS For Linux
·
· Score: 1
While I agree with the general thrust of your post, this poor UI is not so much a problem of Linux as it is of X11. The solution is to choose an interface, and to standardize on it. If you love the Windows GUI, then perhaps KDE can accommodate you. If you love the Current Mac OS X or NeXT interface, then there is GNUstep. Personally, I really loved the BeOS UI, and so perhaps BlueOS will shape GNOME into someting else I can love.
The problem you point out was inherited by Linux and its developers. It comes from a far earlier time. Motif and CDE was and early attempt to fix it. Since Linux has come into its own, we have been making much progress (though perhaps not all progress. 4dwm on Irix was pretty good for its place...) Free desktops don't solve the problem yet. I have lots of hope in both GnuStep and BlueOS.
While I completely agree with most of your post, the last 2 sentences still caught me by surprise. I was very much into OpenBeOS, and only cared for BlueOS trivially - namely to enhance Linux and to aid BeOS userland development until OpenBeOS was viable. Then I could forget about Linux in general.
Now you point out that BlueOS is not only valueable in and of itself, but it may even prove better than OpenBeOS by overcoming the strongest detriment to the BeOS - hardware support. If this proves to be the case, then despite the lesser significance of OBOS, it is still significant. OpenBeOS will be Free Software from top to bottom, mostly under BSD style license. The base of BlueOS will remain GPL because of Linux, but the upper levels may be more restrictive.
Another point which is less than definite is that of binary compatibility. There may be a few who could benefit from access to some of the comercial apps which were released for BeOS, and this would probably be the strongest selling point for OpenBeOS if they could pull it off. Of course Linux could always attempt binary compatibility as well, but that is even less likely. Consider the lack off effort Linux has shown in this area, as compared to OpenBSD et al. Hell, if BlueOS could be ported to OpenBSD, and OpenBSD worked on a BeOS ABI, then perhaps I'd have my end all Be all OS.
Yeah, that pun was intended. Of course, OpenBSD would still be lacking in its threadedness compared to Linux and NewOS (OpenBeOS). Perhaps I should just give up and go to sleep... maybe those dreams will be more coherent.
What is the pertinent difference between USB and BeOS?
Apple dropped support for BeOS early on, while they pushed for USB. BeOS would have sold more Apples, helping Be and Apple. Instead, USB 2.0 isn't even supported on Macintoshes, and Apple's Firewire standard suffers.
Nevermind the catch-22... Apple made the wrong choice and chose Intel over Be. Both Apple and Be died, Intel gained immensely. Then Intel supported BeOS. Apple could have bought out Be, but they didn't. Instead, Intel pushed Linux, Apple reclaimed Jobs, and Be dies. In the long run Apple succeeded overall, but at the cost of Firewire, Mac USB, and BeOS.
Of course BeOS proper is static, so it is dead. But the BeOS APIs stand to "gain from more exposure and may get new development." These BeOS APIs are still used by existing BeOS systems, as well as the future OpenBeOS.
The BlueOS is not simply the GUI, it is also the APIs. NewOS and Linux can use these APIs, and both will benefit. This will also be good for *Be.
-castlan
Fragmentation? You misunderstand...
on
BeOS For Linux
·
· Score: 1
At the risk of restating the obvious, GNU is Not Unix. "Linux" is GNU, in that it is a Free Software OS that depends on the Linux kernel. For someone so "insightful", you don't seem to grasp some very fundamental concepts.
That being said, there is nothing "Free" or "Linux"-like about Mac OS X, other than it's POSIX compliance. If that is significant, than Linux users should just as readily get behind Solaris, or any other commercial Unix. Even Windows NT/2000 offers the option of POSIX compliance, with proven useability for Joe Sixpack. If Mac OS X will combat Windows, it fights Linux just as much. If your mother leaves Windows for Mac OS X, that might hurt MS, but it doesn't help Linux, or any other Free Software.
The point of Linux is not supplication to the Church of Unix, which is as corrupt as the Cult of Microsoft. That end would be more directly achieved by supporting SCO/Caldera. The most important point, which is glossed over in all of this hype over the "Open Source Linux OS" is the Freedom.
This is the exact environment that bred the Open Source Darwin component of Mac OS X. Yes, developers can access the source code - but Darwin is not Free. Similar confusion led to hype about BeOS being based on "Linux". Like Mac OS X, BeOS had nothing to do with Linux, but it did leverage GNU utilites, providing much functionality that is associated with Linux. GNU and Linux don't you to destroy Microsoft to be successful, they can only succeed by the strength of their own merits. I find it very disingenuous of you to claim that popularity of Mac OS X will further interest in Linux.
That is not to say that Mac OS X is not an excellent system. If I had OS X handy, I wouldn't care very much about Linux or other Free OSes either. The point is, I don't. To run such an excellent OS, one requires a currentl Apple system. To hack on it requires complete submission to the Cult of Apple. Together, that can prove unduly expensive. BeOS was almost as good as OS X in most aspects, and superior in a few. It ran on a much wider variet of commodity hardware. While the kernel wasn't Free or Open Source, there was much openness in the higher levels... almost the inverse of Mac OS X.
While BeOS was doomed to die with Be because it wasn't Free Software, at least some of the higher levels are still available for society to enjoy. This is being leveraged in both OpenBeOS and BlueOS. So KDE or GNOME alone won't make your mother leave Windows... perhaps BlueOS will!
Mac OS X is NOT Linux's true way to combat Windows! Mac OS X is an alluring, but very dangerous trap that is just as bad as Microsoft. BeOS was once just another detour from freedom, but in its death, it can atone for it sins. It can lend some of its strengths to Linux via BlueOS, and the BeOS may live once again - this time, basking in the glory of Freedom.
-castlan
yeah, this was a bit over the top. But then again, the parent definitely doesn't deserve +3 and +4 Insightful.
It seems that OpenSSH is still being integrated into the main archive of Debian, Woody (aka 3.0) is still awaiting release, and there is no specific holistic proactive security project. Nevertheless, portability, correctness et al. are definitely emphasized. Now the binary emulation may seem a dubious feature in many cases, especially with Linux occasionally recieving more support than many commercial Unices, though there are some efforts at binary emulation on Suns.
Okay, I'll admit - this was a troll. OpenBSD is still very valuable and viable, and still the best choice for security minded situations. But as yet another bulwark of OpenBSD is breached by Debian, this topic will again merit reevaluation. I still feel that the distant future will find OpenBSD being outpaced by whatever system the Debian Project presents, be it still based on Linux, a more direct BSD derivative, or a more direct embodiment of the GNU System.
I suppose trollvertising is inexpensive, but how effective is it? I'm fairlt sure that most of the limited audience you'll encounter would be put off by your method. I know that I never thought much of you based on your previous posts.
Persistence is nifty, how does it handle data corruption? Do you use a filesystem, and is it fault tolerant? What kind of security model is employed? How does it boot? what kind of UI do you advocate? I have heard a bit about exokernels, but I honestly can't recall much about them at the moment. Mach is admittedly ancient, but have you tried L4? How does your exokernel compare to a more recent "2nd generation" uKernel? Do your "failsafe core kernels" need to reside on the same machine, or are they network aware so that one system image can be distributed amonsts various hardware? Do you have a full BSD userland, from "top" to "whoami"? As for keymapping, both AT and ADB keyboards have escape keys. Did you ever consider equating "command" with the "windows" key? Then esc can be universal, and you have other options for keyboards without the Win95 keys. Do you use the Mac "power" key? You might consider linking it to the Win95 "menu" key (which exhibits right mouse functioanality in Windows, next to the right ctrl key.)
Well, that was about 21 questions. For the record, I actually use/. as my primary news source, and then as a barometer of public opinion. Perhaps this isn't the General Public in many cases, but amongst the rabble it does include a higher caliber of individuals than I usually encounter on a daily basis, and with much less social effort. The Newspaper is only for the rare particularly intriguing stories, as it tends to be unweildly. The television, while requiring much less effort, is too agenda oriented for my tastes, and ususlly fairly ignorant about issues so that I know more about the interesting topics then they do. Radio news is only interesting when I'm driving... otherwise, Opie and anthony is usually more entertaining.
Slashdot can be entertaining, informative, and If I really want balance, I can always read at -1. Plus I get to dispute the morons!
Intel isn't IBM. When Intel gets their chip process under 100 nanometers, they may look into providing multiple CPU cores on one die, as IBM does today.
While what Intel is working on now is unrelated to what I was giving IBM credit for, you are correct in that IBM RS64 III and above offer HMT. This would mean that I was initially incorrect: this would be an "expensive hack".
The reason performance with some workloads can increase by 22% and not double, is that the CPUs are not doubled. It it not a good idea to lie to your computer, and that is why HMT is disabled by default. HMT falsifies the CPU information presented to some system interfaces, which can cause problems. It invalidates the dynamic CPU allocation feature, which seems to me a more important feature. To altering the allocation of physical CPUs is dynamic, while enabling and disabling this dubious feature requires a reboot? That is unfortunate.
Most strinkingly, While HMT under Windows is most valuable in single processor systems, to enable multithreaded code, it is not even an option in single processor AIX systems. Even singlethreaded code will benefit from double processors, as it allows double the threads to execute. This is not the case for HMT's "virtual" doubling, as the thread will never idle, allowing the next thread to take over.
In fact, HMT seems just an attempt to compensate for the limited threading model of Unix-generation systems. While moving the thread scheduler into the hardware is theoretically the best way to get the performance necessary for a responsive threading performance, it shouldn't be necessary to lie to an insufficient interface to achieve it.
I do agree that that the performance improvements of HMT should be achievable, but instead of violating interfaces, those interfaces should be fixed. I recall running Distributed.net's client on a 16 way Onyx. When they implemented CPU autodetection, the client would automatically spawn 16 threads, completely bogging down the system. In a matter of seconds the system was almost completely unresponsive, so that I had to use a serial terminal to kill the thread. When I specified that only 15 threads should be spawned, the responsiveness was silky and smooth, even as I watched the threads shift around between processors (which were running at different clock speeds). Why didn't running one thread on an O2 produce a similar effect? It seems that the Unix legacy is still carrying baggage from its single processor origin in its scheduling model. I would love to see if running the Dnet client on an SMP Linux box (preferably 4+ CPUs) would produce similar results under 2.2 or 2.4, as it seems that Linux has actually made the most progress in this area, despite SGI and IBM's capability of running Single partition system images on hundreds of processors.
I would actually like to play with an SMP Xeon with HMT, so that I could but BeOS on it and see if it's nifty little scheduler fares any better, in light of it's "pervasive multithreading".
If they are the same technology, then it is really too bad that Intel couldn't just use the more desriptive term "Hardware Multithreading". Doesn't this technology just come from the alpha anyway, or did IBM develop it first?
BTW. You really should get an account. It is free, and it makes me feel better about responding to your post with any amount of effort, as there is a better chance of you actually seeing my response, and lets me recognize you for future correspondance. Thanks for the info about the RS64 line. I really haven't looked into AIX much since we moved to LinuxPPC.
I am sorry, but I have to object the the term "narrowband" if it is going to be used to corrupt the definition of broadband. Your second definition of broadband is little more than an after the fact improvisation, based upon the commercial "buzzing" of increasing availability of network connectivity more desireable than traditional dialup access.
Buzzwords are nothing but noise, they generate "heat but not light", and are a general waste of time for those outside of the advertising industry. They also tend to make ignorant an otherwise informed consumer, and so should be avoided at all costs, less they take on airs of being legitamite information.
There are plenty of terms that will accurately describe recently available means of connectivity, including data over coax cable, data over datellite, and various forms of Digital Subscriber Line data over POTS copper cabling. Unfortunately, "Broadband" is the term that the predatory psychologists known as "marketers" have chosen to corrupt. With each passing day, language is further abstracted from expression... "free" means "gratis", "hacker" means "vandal", "peace" means "war", "freedom" means "slavery", MMII is MCMDXXXIV
Should you stop running Seti@home? Most definitely you should stop!
But not because of heat issues. As long as you aren't overclocking your components, and have adequate cooling, then your computer should be fine. but aren't some things more important than your computer?
Let me ask you this: Have you even considered what would happen if we actually did make contact with alien life? If they are sufficiently advanced enough that we could communicate, then most likely they are at least as advanced as we humans in other aspects as well. The aspects I am concerned with range from political ambition, to weapons of extreme destructive technology!
What if they invaded America? They could reveal just how fragile the current state of our republic is, in light of its stagnation under the "two party system"! If they "bodysnatched" the presidential candidates for both the republican and democrat parties, the we would have no choice but to vote for one of them! As stated by Kodos and Krang, you couldn't vote for a third party, as that would just be throwing your vote away! So don't blame Homer J Sixpack.
What if they penetrated the White House's security by posing as a curvaceous floozy or hard working intern? From the "JFK room" they could chew nitrogen gum and frustrate our president with their sexy artificial bodies. Then when we finally have no choice but to use our nuclear missile against their mothership, the head alien would inhale the formidable payload and become pleasantly intoxicated. Then they would destroy all of our civilization, and most of the people, so that no one remained but Natalie Portman, who would have the task of repopulating our cities, and effectively mother the entire human race!
...actually, that doesn't sound half bad. Forget that freak with his Gramma's record player, if I got to share the bunker with Natalie, then I'm all for it! C'mon then, get cracking! How many units have you completed? Don't dally man, this is the future of the Human Race we're talking about! And while your're at it, do you think you could get me a box of grits? Miss Portman likes 'em hot.
Does this actually work? How many people are using your exo-skeleton OS? Do you charge for it? Is it capable of running on a non ia-32 platform? If not, why don't you put some of your efforts into the Mach MicroKernel, which has been ported between at least ia-32 and PPC. Then you could just implement your BSD clone in the style of the lites single server... or even as multiple services if you really truly do have your kernel split up as autonomous daemons as you claimed in a previous post to me. Perhaps you could raise a flock, gaggle or murder to outflank the hird of hurds of GNUs that will soon trample you.:P
silly, silly troll. You could really teach ideut blah1394@hotmail.com a few lessons about steadfast persistence. You definitely make a much better "ideut".
But so what, it's not like I have a life at this very moment. So I've waited a business week, can you continue this conversation yet?
Any _real_ troll worth his salt would not surrender so easily. Any respectable conversant would realize when they were mistaken, and submit with honor. Only sneaky vermin such as yourself would scuttle off and pretend it was an act of generosity. That is not to say that you wouldn't be doing us all a favor by just going away, unfortunately, your kind tends to reinfest after the lights go out again.
So, step into the light. Are you a man, or are you a mouse? (Because you definitely aren't a troll. The billy goat would have easily kicked your ass.)
Perhaps you are correct. In this case, "Debian" is not so much an entity, as an umbrella for the maintainers who volunteer their time. If this is a problem, then the answer is to report the bug, so that the maintainer is aware of it. If the maintainer is unresponsive after a reasonable amount of time, then one can always package the newer version which fixes the bug, as per the directions in the Debian developers section. This fixes your immediate problem. To help the Debian comunity, raise the issue via the appropriate Debian mailing list, and volunteer your updated dpkg as a candidtate for a Non-Maintainer Upload (NMU).
I still feel that for packages I am aware of, bugfixes are considered important, and are usually timely, if not subject to "fix in 24 hrs or your money back!" If you disagree, there are always options. If you need such guarantees, you can always pay for Debian support. One such company is Progeny Linux who used to distribute a very useable GNOME centric distribution called Progeny Debian. I believe they still maintain it somewhat, though it never made it past the "Newton" release, and they recommend that users upgrade to the current "Woody" release of debian 3.0. *sigh*
I don't believe my post was flawless in any sense! Does that mean that it didn't have iny information worth reading? I am very dissapointed by your reaction here, especially the victim mentality. How did you not get a chance? Despite your fears to the contrary, you were not modded down. There was no summary judgement or execution by the Slashdot wing of the "Debian Community" You were hardly excluded, and just about every post with positive moderation was very fair and even, not rallying against any people expressing "counter-Debian" sentiments.
I really wish that I didn't see this post. Perhaps a negative moderation wouldn't have been uncalled for in this case, if it obscured this post. I suppose that is because I find/. karma probably isn't as valuable as respect.:(
It seems that I mistook your quantity of cluefulness.
While well thought out standards are a good thing, some standards are meant to be broken. Seeing as how the LSB came after the fact, nonconformity could hardly be considered an act of fragmenting Linux. That is not to say that standards are not a worthy goal. The issue here is that Debian is sticking to a standard that was well defined before the LSB was concieved, before the FHS was called the FHS. This publicly available standard predates the concept of Open Source. The Debian Policy Manual is what makes Debian a paragon of Free Software, of open practices, and a positive institution in general.
It seems the the LSB is less of a standard to aspire to, then a LCD (lowest Common Denominator). While interoperability with the LSB as stated is an important goal, that does not mean that extra functionality, non-standard enhancements, or even differing but equivalent mechanisms should be wholly disposed of. That would just prevent evolution, and advancing the state of the art.
You say that Debian should cast off Dpkg in favor of using RPMs internally. Does that mean that Red Hat should condemn and avoid all post 3.05 RPMS? While Red Hat uses a package format with the same name as the LSB packages format, they are distinct packages. There is nothing wrong with Red Hat improving their RPM package, which is distinct with LSB RPMs. As long as an avenue of interoperability with LSBs is maintained, then they are compliant. Likewise with Debian. You said that Debian should quit dpkgs and work to improve RPMs. That would be of absolutely no benefit, because even if RPMs grew to be feature compatible with currrent dpkgs, those RPMs wouldn't be LSB RPMs.
Perhaps Debian dpkgs contain control information above and beyond that specified by the LSB. Are you suggesting that Debian cut off its left hand to be more conformant? As long as Debian can use alien to produce LSB RPMs (that would be missing the enhanced control info) then there is no reason to use RPMs internally. And just because alien can process LSB RPMs into less capable dpkgs doesn't mean that those RPMs should be preferred over less restrictive dpkgs.
Hopefully you can see that debian using dpkgs are a good thing, and have no downside as long as there is still an avenue for LSB RPM interoperability. But since the LSB mandates RPM, the Debian Policy Manual cannot incorporate the LSB wholesale.
Just a few more minor points.
I still stand by my statement that raw.TGZ archives should be sufficient for software developers release. As maintainer of your Red Hat APT repository, do you really trust each developer to know the complete workings of your specific supported system? You would have to at the very least proofread and tweak the control information yourself if your goal is to maintain a useful repository for stable systems. To make my point even more extreme, packages are a convienence of efficiency, but not a strict need. If all "packaged" archives were statically compiled, then you would have a relatively heavy but interdependancy resilient collection.
Also, at no point did I say "APT packages". As I stated a few paragraphs ago, dpkgs currently are more expressive than LSB RPMS, so they would be preferred. I said
Even if you had the [LSB] compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.
In other words, the 3.05 RPM of Red Penguin's PPPoE is less valueable to a Debian system then a current DPKG version. This RP-PPPoE is readily available in the standard Debian repostory, so rather than installing an unverified or out of date version via dpkg -i, it would be best to use the standard.dpkg version via the standard APT repository. I can imagine that you are sensitive to this issue, being the maintainer of an APT/RPM repository, but I in no way stated that RPMS are APT proof.
In contrast, it seems that RPMs are more "network aware" than DPKGs. One cannot simply #dpkg -i http://127.0.0.1/distro/rp-pppoe.dpkg as you can with RPMs. DPKGs are an implementation of the worse-is-better philosophy, completely depending on an external transport mechanism like APT, so that each can focus on their specialized strengths more efficiently, with less complexity. I guess that RPMs are trying to be all-in-one integrated solutions. the existense on your repository seems to rather clearly express how good RPMs handle that. I must admit, I was not aware that APT/RPMs were common just yet. I just knew that some Brazillian Distro (connectiva?) had developed them, and they had seemed to fall behind in APT development. What shortcomings do you see in uRPMi that APT/RPM handles better?
Have you checked the alien maintainers web site? He has a fairly thourough comparison of DPKG, RPM and TGZ(with slackware control info). Going solely by the list of features, it seems that perhaps it would be less work to add Red Hat RPM's good features into DPKG. Though I still wouldn't want the LSB updated to this new DPKG+RPM format. The value of RPM 3.05 is that it is unambiguous, being fully defined and specified in Maximum RPM, and so there should be no reason why any arbitrary OS couldn't maintain interoperability with it.
Alright, so you are at 50 karma, does that really mean you should post distorted rhetoric? I guess what I want to know is, do you believe half of what you have been posting in this cluster of threads? And did you really gain all of your karma points posting like this, or did you flip the troll flux capacitor when you reached 50? If it is the former, then I guess that you are the best argument for raising the Karma cap that I've recently seen.
Just various points, this isn't a zero-sum game. Macs only compete with systems providers in a general sense, but this is not strict competition, as there is not 1:1::human:computer ratio. Macs don't compete with Linux or Windows in any real sense, as Linux runs on Mac hardware, which is where Apple makes its money. Windows competes even less, because it doesn't run on Mac Hardware. Apples biggest "competetors" are their own development, production and advertising costs, in trying to win back new hardware sales from previous customers.
Apple and Linux need to cooperate... not against Windows, but for the advancement of consumer level computing for all. Macintosh has significantly developed the modern WIMP interface, the Windows 95 interface, and the KDE interface. This is already accounting for the invention of the foundation technologies at Palo Alto Research Center. If Apple (burned/fell-from-earth) then Linux developments in a desktop capacity would be seriously harmed, as the GUI would be locked until a later generation invents the feasible post WIMP GUI. This will take much too long without Apple's guidance, especially if we look to Microsoft for guidance. (Bob 2K? Can't wait!) Note that this is completely ignoring all direct MkLinux development, and lots of other Linux-indirect Unix development from before Linux's conception to modern day work.
Can Apple make their own way? They've been dying longer than Linux had been Buzzing. It looks to me like Apple's great fall is really just a LEOrbit. In another post you say same nonsense about Linus not support Apple. Apple already played the Linux game. They switched MkLinux for MkBSD/Lites server, so that they can restrict their system... almost like a Real UNIX, except that it still qualifies as Open Source.
Speaking of Real UNIX, how do you feel about them Unices as an OS? "In fact, I'd say I like the OS less because it's even more restrictive than Windows is (you have to buy very specific hardware, all approved by , and most of it overly expensive). I see no justification or need for cooperation between Linux developers and Apple." Care to replace all instances of Apple with NeXT? Okay, then how about any other Unix vendor?As for justification, it is the same with Linux as with with any other Unix. It's called the Portable Operating System Exchange standard, and it is the only RMS independant reason that Linux exists. While I have many harsh sentiments towards Jobs, many people would rather sit with him then Stallman - more flashy, less preachy.
Is Jobs and Co. capable of making their own way? I dunno, in a commercial sense, which Linux developer - hell, which handfull of Linux Resellers are doing better than Apple?
Hey Max, keep trolling, cuz you sure got my goat tonight. Now I'm gonna count sheep instead.
Before I respond, what I really want to know is, does anybody know what ever came of the project to implement the Mac OS X GUI in x86? I know there was a project on sourceforge called achelous, but that hasn't been updated in quite some time. Does anybody have any information here? DisplayPDF and Quartz would be quite nice.
One point that seems to have been overlooked is that Mac OS X is theoretically more portable than FreeBSD or Linux. See, Mac OS X run on Darwin which is hosted on an implementation of the first generation Mach Microkernel. The Mach subsystem really isn't fully utilized, as both MkLinux and Darwin only run as single servers, neglecting the promise of microkernel technology. But the advantage that wasn't completely wasted was the hardware abstraction. Back when Linux was pre 2.0, the criticism was that Linux wasn't portable. Really it wasn't, but that didn't much matter if each implementation presented the same APIs, because then they could be interchangeable.
Back to the point, while Mach wasn't ported quite as widely as NetBSD or subsequently Linux, it was ported to at least PPC and x86. Running on Single servers running over Mach, Higher level services are really quite abstracted from the hardware - I'm not even sure that endianness should be an issue in this environment. So complexity (which already exists in abundance, from Mach-BSD-Quartz to Carbon/Cocoa/ClassicEmu) isn't significantly increased. In fact, the Mach-O binary format could fairly easily use Fat Binaries for everything, which means there is even less potential complexity to manage. Fat binaries have been extensively used in the past, both in 68k/PPC on classic, and 68k/x86/more on NeXTs yellowbox/cocoa environment. As for Mac OS X itself, in addition to your other arguments, I don't see how this could be a bad thing.
As gwernol already pointed out, just about all of the problems you pointed out could be solved by supporting Mac OS X-x86 only on Apple branded hardware. This would readily solve the basic driver problem, by defiing a known quantity. If a driver will work on Mach, then it should probably be independant of hardware platform, based on Mach's claim of true portability. (This is probably giving too much benefit of the doubt.) Then there could be an Apple certified hardware list, which should indicate compatibility on both platforms.
More of benefit to the x86 architecture in general, this would be the perfect excuse for Apple to introduce an x86 PC using Open Firmware, destroying reliance on the damned archaic IBM-refuse/early-Compaq-era PC BIOS forever! I'd gladly buy one of these to forget about all of the crufty limitations and hackish workarounds carried from the PC-XT et al. It should be fairly reasonable in price, as they wouldn't be integrating a Unifed Memory Architecture integrated into the graphics hardware like SGI did with their PROM based Visual Workstation series (which blew crude PC BIOSes away). It would be bringing a common standard shared by Sun and Apple to the common PC, increasing flexibility and robustness, from booting to remote administration, even over a serial port. I'd buy one of these in a heartbeat. (BTW, IBM didn't much care for the IBM PC, so it didn't care to expend to effort to pursue Compaq. Apple most definitely would not let any would-be Compaq get away with that, as is proved when {Sinclair?} tried the same thing - and don't forget about E-machines.)
The real danger in all of this, after all of the hyped benchmarking nonsense, would be if Mac OS X running on Apple x86s turned out to be tangibly more performant than on Macintoshes. If the Macs weren't indisputably the higher-end professional choice, it would impact the company. This would cause Apple to bleed money, as Mac Hardware sales would drop dramatically in light of this. It is a distinct possibility, when you consider that Mac OS X is very heavy on graphics useage. Graphics acceleration was very primitive on the Macintosh platform. In true chicken-and-egg fashion, it is likewise on classic Mac OS, and still lagging on Mac OS X. The much more mature transform and lighting capable hardware running on more finely tuned and fully enabled AGP 4x chipsets could have a significant impact on user responsiveness and percieved GUI performance. Additionally, the clock speeds and thoroughput on x86 machines are much higher, on CPUs, but more significantly on the system bus and especially in the memory subsystem. Another consideration is that Mach projects have had considerable development on x86, so it might possibly perform better then on PPC. These combined could show real impact on general system performance.
This is why emulation would be a Good Thing. The Red Box (hey, lets call it the Caffeine Windows API. Red Box was removed from Rhapsody, but it is viable on x86, especially since OpenStep ran on Windows. If not, Apple could always buy Caffeine from Virtual PC, SoftWindows, VmWare or even BOCHS--making a "Red BOCHS") would be another layer of overhead to slow down the system. More interestingly and effectively, Apple could provide a Carbon/Blue Box element to Mac OS X-x86. If some standard Carbon functionality was required by the base system, as it is on PPC, then the x86 platform could be hobbled as much as needed, while the value of the system would increase significantly. Fat Mach-O binaries could be universally portable between x86 and PPC, for ease of commercial software software distribution (shelf space) and support. The masses could see exactly how Microsoft Office apps are better on Mac OS then on Windows, and Mac OS X would finally gain a glut of gaming software.
I knew Mono was supposed to be highly contagious, but I didn't think it could jump species! That's what happened with AIDS, in other species (like simians-SIV*, bovines-BIV** and especially felines-FIV) it was harmless, but when it jumped to humans it became deadly. Does this have something to do with the Viral nature of the GPL? I guess Microsoft knew what they were talking about after all. Poor Gnomes... that's probably why you can't keep them as pets. Same thing with penguins at the South Pole - you can't get too close to them or they will get sick and die because their immune systems aren't as strong as ours.:(
I don't understand why anyone at the Register would show any sympathy for any of this. I'll bet they're happy about all of this misery. From what I understand, they're a morbid bunch of vultures over there!
* Not sure about Ximians and XIV, though I think that they were the first to develop Mono.
** I understand that Bovine cracked DES. I'm not sure how that compares to other viruses, but it sounds just awful.
-castlan
*** What are you looking for, I didn't use 3 asterisks anywhere in my post! Get out of here! I said SCAT! Shoo! Run along.****
**** Alright, if you really need more information of how FIV might have jumped to humans, you might want to look here
The potential of "Many eyes make bugs shallow" only applies to unit or even component testing, which can be fairly effective if there are enough well defined black boxes. The trouble comes when the white boxes are large, and system testing requires skilled and dedicated eyes.
As for Sardonix, how fine grained is their code auditing credit system? As I previously stated, does a fairly trivial component rate the same as an involved Mozilla audit? Can audits with a white box be distinguished from an entire system audit?
Your general point is well taken, but that hardly makes this article a waste of time. Security is still more of an art than an exact science, which makes skilled administrators more valuable than any general distribution of an OS. While the article could have put more emphasis on this point, it does do a service in rasing awareness of this issue, for further research, and while not advancing the state of the art, perhaps it has helped contribute to the state of the science.
As for being a waste of _your_ time, that is quite likely if you are already an administrator worth your salt. In contrast, it is a potentially very important article if you happen to be a salty old administrator who distrusts non-commercial software.
Irix tends to use/etc for binaries that Linux would put in/sbin. Filesystems are fairly arbitrary and cosmetic, so I don't think that filesystem tree layout is a good way to determine Unix lineage. The FHS project is a literal example of this, as many Linux Distros shuffled file layout to gain conformance. Most Unices use BSD sockets, including Linux, even while other parts may be SVR3 derived. SVR5 is arguably BSD derived as well, or at least subject to cross-pollination.
Your post seems at least misguided, and inappropriately antagonistic. There may be facts of which you are not aware. Of course, before you go quoting me, research the facts yourself, as I am pulling the SVR3 and SVR5 references from out of my ass. I apologize for using "facts" that are likely distorted.
So registering with this site allows a record of your auditing ability. I wonder how this project would compare someone who autited a simple program like test.c versus say Mozilla running on QNX.
Your journal did not llow me to respond, so I had to post here to communicate with you. Since this discussion is "illicit" (offtopic) I am more concerned with raising issues than presenting a clear and concise argument. Please keep that in mind.
I do not disagree with the basic argument of your journal entry, but with your first assertion, regarding the definition of the term piracy.
Piracy is the boldly commited illegal act of violent misappropriation of goods or property, as in robbery. Robbery, a public act, when commited in transit over distribution channels, originally over the high seas, is piracy, though it can also apply to hijacking an airplane, or carjacking a delivery truck. The violence of robbery is enough to demonize it, but the large scale of violence makes it a more effective term than "software robery."
"Software piracy" is a misnomer, as is "software theft". Your arguments apply to the phrase software theft, which would be individual acts or crimes. The term software piracy leverages a loaded word which is more damning than simple theft, as piracy alludes to a violent large scale operation, akin to "organized crime" taking place over unpopulated areas such as the open ocean, or as it were, the Internet.
"Software theft" really amounts to unauthorized reproduction of information media. It seems the closest analog of this behaivor before the Internet became a pubic medium would be linked to the behaivor allowed by the Gutenberg Press - copying the Bible for mass distribution against the will of the "catholic" church, which restricted biblical access to ordained priests, so as to preserve their power structure.
This metaphor is not quite correct either, because there is a differnce between the archaic church as it existed centuries ago, and the modern day entertainment media production and distribution houses. This differnce is admittedly ideological, and not as subject to linguistic corruption. I'd say it falls somewhere in the spectrum of the ideologies of Capitalism versus Communism (economically, not with respect to practices of governance.) In contrast, the organized church did use this restriction as an improper form of goernance.
Another interesting attempt at demonizing unauthorized media distribution is the term bootlegging as applied to software. This term seems more accurate than "software piracy" especially in light of your journal post, as bootlegging doesn't involve embezzlement or theft(preventing useage by the rightful owner) but smuggling or illegal distribution. Bootlegging is also not as associated with violent behaivor, so wasn't as succesful (sensational) a term as was piracy. Bootlegging is a bit too crude of a term, as software bootlegging deserves a more refined term. The software itself is not contraband, as was prohibition era alcohol. The question is whether "bootlegging" is based on the act of possessing an illict substance with transportation being incidental, or illegal transportation with possesion being incidental. This might be considered in light of how in some States* alcohol is/was legal to possess for personal use, but not to transport/sell. Similarly in some places alocohol consumption wasn't criminal, just possesion. Both of these two situations seem engineered to "grandfather" those who had obtained alcohol prior to it becoming illicit, but to dry out future uses of alcohol.
One last interesting phrase to consider is "pirate radio". In contrast to using a legal medium to illegally distribute, this refers to illegally using a medium to distribute otherwise legal material. This would illustrate that the term "piracy" is far overused, in danger of corruption beyond resonable definition, which is unfortunate considering the source of the corruption. Being a natural language, useage determines the definition of words, published dictionaries are more akin to surveys then definitive useage manuals. The benefit of useing a natural language over a synthetic language, is the inherent flexibility makes it powerful. The problem arises when mass media uses its power to derail a language by propogating contrary or distorted definitions. The end result is the worst kind of synthetic language, because the expressive power is deliberately crippled with regard to issues that the media house has a vested interest in. In this regard, the insidious corruption of language (piracy, hacking, free, communist, punk, nigger, holocaust, civil disobediance, liberal, and just about every other "loaded" word you can think of) is at best unfortunate, and at worst just as bad as the orignial "catholic" church restricting mass reproduction of the Bible in order to opress civilization.
Slashdot Moderators: If you have read this far, but were offended, then you at least found this post interesting. So if you can't think of a response, perhaps you should moderate this as interesting so that another may see it and post an appropriately damning response. If you mark this as offtopic despite my warning in the title, then you are likely doing the community a disservice. If you feel this is simply a troll with no redeeming content, then moderate it as a troll unworthy of public resonse. I don't think "Insightful" would be appropriate for this post.
Slashdot Mirror
Flamebait perhaps, but not Off Topic. Integrated crypto is a significant feature of OpenBSD. Now Debian has the capability to integrate their crypto. This will propel Debian forward significantly into areas where OpenBSD was once undisputedly the better choice. Perhaps instead of ignorantly moderating, you could have actually posted a response. Of course, that assumes that you are capable of intelligent communication. My bad.
BeOS was always an Operating System vendor. They set out to prove that modern technology could make an elegant system without archaic cruft. They proved it to me... a Mac 7600 running at 120 MHz was hardly a media powerhouse. Running one movie was pretty stressful, don't even joke about running two movies at one time! And then load the BeOS onto the very same hardware, suddenly you can run 6 movies at once, and the little Mac is still fully responsive.
Some of the primary technologies, multithreaded multitasking etc. were intended to leverage the cost effective power available with multiple cheap CPUs running in SMP. For the price of one 200 MHz CPU, you could have bought two 133 MHz CPUs instead, and still saved money. Because SMP machines weren't common at the time, Be developed a box which ran on the Hobbit CPU, because they were the cheapest CPUs available. Later they ported to the Motorola 603, which was also very cheap any very plentiful. Even though the 603 wan't intended for SMP (as was the 604), it was so cheap in comparison that it was still worthwhile to make a custom 603 SMP box instead.
Now that is where your 1st point is off the mark. After supporting the PPC architecture, Mac PPCs were a trivial addition which were worthwhile because they were a relative commodity item. After BeBoxen were no longer cheaper than Macs, the BeBox was discontinues. All along, Be was a modern OS. With the Mac embracement, they started to pla on the "Media OS" angle, but that isn't quite as drastic a shift as your story tells.
Now maybe it wasn't illegal, but it was a monopoly which arguably killed the BeOS. Apple under Gil Amelio was so hospitable (With the clones and such) that Be was lured onto their platform. Then with the return of Jobs, that platform was pulled out from under them. Be was already working on their Intel version, but IMHO the switch was definitely premature, and I was definitely saddened by the sadist returning to Apple, destroying all of the cool things I loved (BeOS, Power Computing...) and having the nerve to claim that I would have just bought an Overpriced Underpowered Apple anyway in a mass mailing I recieved.
Of course, being Commanded from the once Open Apple, they were forced onto the ocean of the Intel world. The dread Pirate Microsoft ruled those waters with impunity, using whatever ruthless tactics they could get away with. Be tried to defer, and claimed to only be a "Media OS" for niche purposes, and not an outright "general purpose" competetor to Windows, even if they were fully capable of it. During yet another Wintel Spat, Intel poured lots of support into Be, making MS jealous, and dooming Be off of the general desktop platform, into the reclusion of the BE-IA space. Of course Microsoft used its Monopoly to illegally bully hardware vendors into being MS exclusive. If they tried to offer a Windows Alternative, they would have had to cough up all of thier lunch money to Microsoft for the privilegde of selling Windows on any of their systems. If they were exclusive with Windows, then the rates were much reduced.
There were many reasons why Be didn't make it. But your alleged lack of focus was merely a symptom of the problem. All along, Be was focused on supporting and promoting the BeOS, thier "fully modern Operating System." Everything else was incidental.
-castlan
While I agree with the general thrust of your post, this poor UI is not so much a problem of Linux as it is of X11. The solution is to choose an interface, and to standardize on it. If you love the Windows GUI, then perhaps KDE can accommodate you. If you love the Current Mac OS X or NeXT interface, then there is GNUstep. Personally, I really loved the BeOS UI, and so perhaps BlueOS will shape GNOME into someting else I can love.
The problem you point out was inherited by Linux and its developers. It comes from a far earlier time. Motif and CDE was and early attempt to fix it. Since Linux has come into its own, we have been making much progress (though perhaps not all progress. 4dwm on Irix was pretty good for its place...) Free desktops don't solve the problem yet. I have lots of hope in both GnuStep and BlueOS.
-castlan
Amen brother.
While I completely agree with most of your post, the last 2 sentences still caught me by surprise. I was very much into OpenBeOS, and only cared for BlueOS trivially - namely to enhance Linux and to aid BeOS userland development until OpenBeOS was viable. Then I could forget about Linux in general.
Now you point out that BlueOS is not only valueable in and of itself, but it may even prove better than OpenBeOS by overcoming the strongest detriment to the BeOS - hardware support. If this proves to be the case, then despite the lesser significance of OBOS, it is still significant. OpenBeOS will be Free Software from top to bottom, mostly under BSD style license. The base of BlueOS will remain GPL because of Linux, but the upper levels may be more restrictive.
Another point which is less than definite is that of binary compatibility. There may be a few who could benefit from access to some of the comercial apps which were released for BeOS, and this would probably be the strongest selling point for OpenBeOS if they could pull it off. Of course Linux could always attempt binary compatibility as well, but that is even less likely. Consider the lack off effort Linux has shown in this area, as compared to OpenBSD et al. Hell, if BlueOS could be ported to OpenBSD, and OpenBSD worked on a BeOS ABI, then perhaps I'd have my end all Be all OS.
Yeah, that pun was intended. Of course, OpenBSD would still be lacking in its threadedness compared to Linux and NewOS (OpenBeOS). Perhaps I should just give up and go to sleep... maybe those dreams will be more coherent.
-castlan
What is the pertinent difference between USB and BeOS?
Apple dropped support for BeOS early on, while they pushed for USB. BeOS would have sold more Apples, helping Be and Apple. Instead, USB 2.0 isn't even supported on Macintoshes, and Apple's Firewire standard suffers.
Nevermind the catch-22... Apple made the wrong choice and chose Intel over Be. Both Apple and Be died, Intel gained immensely. Then Intel supported BeOS. Apple could have bought out Be, but they didn't. Instead, Intel pushed Linux, Apple reclaimed Jobs, and Be dies. In the long run Apple succeeded overall, but at the cost of Firewire, Mac USB, and BeOS.
--feeling dizzy
Of course BeOS proper is static, so it is dead. But the BeOS APIs stand to "gain from more exposure and may get new development." These BeOS APIs are still used by existing BeOS systems, as well as the future OpenBeOS.
The BlueOS is not simply the GUI, it is also the APIs. NewOS and Linux can use these APIs, and both will benefit. This will also be good for *Be.
-castlan
At the risk of restating the obvious, GNU is Not Unix. "Linux" is GNU, in that it is a Free Software OS that depends on the Linux kernel. For someone so "insightful", you don't seem to grasp some very fundamental concepts.
That being said, there is nothing "Free" or "Linux"-like about Mac OS X, other than it's POSIX compliance. If that is significant, than Linux users should just as readily get behind Solaris, or any other commercial Unix. Even Windows NT/2000 offers the option of POSIX compliance, with proven useability for Joe Sixpack. If Mac OS X will combat Windows, it fights Linux just as much. If your mother leaves Windows for Mac OS X, that might hurt MS, but it doesn't help Linux, or any other Free Software.
The point of Linux is not supplication to the Church of Unix, which is as corrupt as the Cult of Microsoft. That end would be more directly achieved by supporting SCO/Caldera. The most important point, which is glossed over in all of this hype over the "Open Source Linux OS" is the Freedom.
This is the exact environment that bred the Open Source Darwin component of Mac OS X. Yes, developers can access the source code - but Darwin is not Free. Similar confusion led to hype about BeOS being based on "Linux". Like Mac OS X, BeOS had nothing to do with Linux, but it did leverage GNU utilites, providing much functionality that is associated with Linux. GNU and Linux don't you to destroy Microsoft to be successful, they can only succeed by the strength of their own merits. I find it very disingenuous of you to claim that popularity of Mac OS X will further interest in Linux.
That is not to say that Mac OS X is not an excellent system. If I had OS X handy, I wouldn't care very much about Linux or other Free OSes either. The point is, I don't. To run such an excellent OS, one requires a currentl Apple system. To hack on it requires complete submission to the Cult of Apple. Together, that can prove unduly expensive. BeOS was almost as good as OS X in most aspects, and superior in a few. It ran on a much wider variet of commodity hardware. While the kernel wasn't Free or Open Source, there was much openness in the higher levels... almost the inverse of Mac OS X.
While BeOS was doomed to die with Be because it wasn't Free Software, at least some of the higher levels are still available for society to enjoy. This is being leveraged in both OpenBeOS and BlueOS. So KDE or GNOME alone won't make your mother leave Windows... perhaps BlueOS will!
Mac OS X is NOT Linux's true way to combat Windows! Mac OS X is an alluring, but very dangerous trap that is just as bad as Microsoft. BeOS was once just another detour from freedom, but in its death, it can atone for it sins. It can lend some of its strengths to Linux via BlueOS, and the BeOS may live once again - this time, basking in the glory of Freedom.
-castlan
yeah, this was a bit over the top. But then again, the parent definitely doesn't deserve +3 and +4 Insightful.
Oh yeah... It seems that the Debian Project is one step closer to supplanting OpenBSD.
It seems that OpenSSH is still being integrated into the main archive of Debian, Woody (aka 3.0) is still awaiting release, and there is no specific holistic proactive security project. Nevertheless, portability, correctness et al. are definitely emphasized. Now the binary emulation may seem a dubious feature in many cases, especially with Linux occasionally recieving more support than many commercial Unices, though there are some efforts at binary emulation on Suns.
Okay, I'll admit - this was a troll. OpenBSD is still very valuable and viable, and still the best choice for security minded situations. But as yet another bulwark of OpenBSD is breached by Debian, this topic will again merit reevaluation. I still feel that the distant future will find OpenBSD being outpaced by whatever system the Debian Project presents, be it still based on Linux, a more direct BSD derivative, or a more direct embodiment of the GNU System.
-castlan
I suppose trollvertising is inexpensive, but how effective is it? I'm fairlt sure that most of the limited audience you'll encounter would be put off by your method. I know that I never thought much of you based on your previous posts.
/. as my primary news source, and then as a barometer of public opinion. Perhaps this isn't the General Public in many cases, but amongst the rabble it does include a higher caliber of individuals than I usually encounter on a daily basis, and with much less social effort. The Newspaper is only for the rare particularly intriguing stories, as it tends to be unweildly. The television, while requiring much less effort, is too agenda oriented for my tastes, and ususlly fairly ignorant about issues so that I know more about the interesting topics then they do. Radio news is only interesting when I'm driving... otherwise, Opie and anthony is usually more entertaining.
Persistence is nifty, how does it handle data corruption? Do you use a filesystem, and is it fault tolerant? What kind of security model is employed? How does it boot? what kind of UI do you advocate?
I have heard a bit about exokernels, but I honestly can't recall much about them at the moment. Mach is admittedly ancient, but have you tried L4? How does your exokernel compare to a more recent "2nd generation" uKernel? Do your "failsafe core kernels" need to reside on the same machine, or are they network aware so that one system image can be distributed amonsts various hardware? Do you have a full BSD userland, from "top" to "whoami"? As for keymapping, both AT and ADB keyboards have escape keys. Did you ever consider equating "command" with the "windows" key? Then esc can be universal, and you have other options for keyboards without the Win95 keys. Do you use the Mac "power" key? You might consider linking it to the Win95 "menu" key (which exhibits right mouse functioanality in Windows, next to the right ctrl key.)
Well, that was about 21 questions. For the record, I actually use
Slashdot can be entertaining, informative, and If I really want balance, I can always read at -1. Plus I get to dispute the morons!
Intel isn't IBM. When Intel gets their chip process under 100 nanometers, they may look into providing multiple CPU cores on one die, as IBM does today.
While what Intel is working on now is unrelated to what I was giving IBM credit for, you are correct in that IBM RS64 III and above offer HMT. This would mean that I was initially incorrect: this would be an "expensive hack".
The reason performance with some workloads can increase by 22% and not double, is that the CPUs are not doubled. It it not a good idea to lie to your computer, and that is why HMT is disabled by default. HMT falsifies the CPU information presented to some system interfaces, which can cause problems. It invalidates the dynamic CPU allocation feature, which seems to me a more important feature. To altering the allocation of physical CPUs is dynamic, while enabling and disabling this dubious feature requires a reboot? That is unfortunate.
Most strinkingly, While HMT under Windows is most valuable in single processor systems, to enable multithreaded code, it is not even an option in single processor AIX systems. Even singlethreaded code will benefit from double processors, as it allows double the threads to execute. This is not the case for HMT's "virtual" doubling, as the thread will never idle, allowing the next thread to take over.
In fact, HMT seems just an attempt to compensate for the limited threading model of Unix-generation systems. While moving the thread scheduler into the hardware is theoretically the best way to get the performance necessary for a responsive threading performance, it shouldn't be necessary to lie to an insufficient interface to achieve it.
I do agree that that the performance improvements of HMT should be achievable, but instead of violating interfaces, those interfaces should be fixed. I recall running Distributed.net's client on a 16 way Onyx. When they implemented CPU autodetection, the client would automatically spawn 16 threads, completely bogging down the system. In a matter of seconds the system was almost completely unresponsive, so that I had to use a serial terminal to kill the thread. When I specified that only 15 threads should be spawned, the responsiveness was silky and smooth, even as I watched the threads shift around between processors (which were running at different clock speeds). Why didn't running one thread on an O2 produce a similar effect? It seems that the Unix legacy is still carrying baggage from its single processor origin in its scheduling model. I would love to see if running the Dnet client on an SMP Linux box (preferably 4+ CPUs) would produce similar results under 2.2 or 2.4, as it seems that Linux has actually made the most progress in this area, despite SGI and IBM's capability of running Single partition system images on hundreds of processors.
I would actually like to play with an SMP Xeon with HMT, so that I could but BeOS on it and see if it's nifty little scheduler fares any better, in light of it's "pervasive multithreading".
If they are the same technology, then it is really too bad that Intel couldn't just use the more desriptive term "Hardware Multithreading". Doesn't this technology just come from the alpha anyway, or did IBM develop it first?
BTW. You really should get an account. It is free, and it makes me feel better about responding to your post with any amount of effort, as there is a better chance of you actually seeing my response, and lets me recognize you for future correspondance. Thanks for the info about the RS64 line. I really haven't looked into AIX much since we moved to LinuxPPC.
-castlan
I am sorry, but I have to object the the term "narrowband" if it is going to be used to corrupt the definition of broadband. Your second definition of broadband is little more than an after the fact improvisation, based upon the commercial "buzzing" of increasing availability of network connectivity more desireable than traditional dialup access.
Buzzwords are nothing but noise, they generate "heat but not light", and are a general waste of time for those outside of the advertising industry. They also tend to make ignorant an otherwise informed consumer, and so should be avoided at all costs, less they take on airs of being legitamite information.
There are plenty of terms that will accurately describe recently available means of connectivity, including data over coax cable, data over datellite, and various forms of Digital Subscriber Line data over POTS copper cabling. Unfortunately, "Broadband" is the term that the predatory psychologists known as "marketers" have chosen to corrupt. With each passing day, language is further abstracted from expression...
"free" means "gratis",
"hacker" means "vandal",
"peace" means "war",
"freedom" means "slavery",
MMII is MCMDXXXIV
-castlan
Should you stop running Seti@home? Most definitely you should stop!
But not because of heat issues. As long as you aren't overclocking your components, and have adequate cooling, then your computer should be fine. but aren't some things more important than your computer?
Let me ask you this: Have you even considered what would happen if we actually did make contact with alien life? If they are sufficiently advanced enough that we could communicate, then most likely they are at least as advanced as we humans in other aspects as well. The aspects I am concerned with range from political ambition, to weapons of extreme destructive technology!
What if they invaded America? They could reveal just how fragile the current state of our republic is, in light of its stagnation under the "two party system"! If they "bodysnatched" the presidential candidates for both the republican and democrat parties, the we would have no choice but to vote for one of them! As stated by Kodos and Krang, you couldn't vote for a third party, as that would just be throwing your vote away! So don't blame Homer J Sixpack.
What if they penetrated the White House's security by posing as a curvaceous floozy or hard working intern? From the "JFK room" they could chew nitrogen gum and frustrate our president with their sexy artificial bodies. Then when we finally have no choice but to use our nuclear missile against their mothership, the head alien would inhale the formidable payload and become pleasantly intoxicated. Then they would destroy all of our civilization, and most of the people, so that no one remained but Natalie Portman, who would have the task of repopulating our cities, and effectively mother the entire human race!
...actually, that doesn't sound half bad. Forget that freak with his Gramma's record player, if I got to share the bunker with Natalie, then I'm all for it! C'mon then, get cracking! How many units have you completed? Don't dally man, this is the future of the Human Race we're talking about! And while your're at it, do you think you could get me a box of grits? Miss Portman likes 'em hot.
-castlan
You silly, troll. :D
:P
Does this actually work? How many people are using your exo-skeleton OS? Do you charge for it? Is it capable of running on a non ia-32 platform? If not, why don't you put some of your efforts into the Mach MicroKernel, which has been ported between at least ia-32 and PPC. Then you could just implement your BSD clone in the style of the lites single server... or even as multiple services if you really truly do have your kernel split up as autonomous daemons as you claimed in a previous post to me. Perhaps you could raise a flock, gaggle or murder to outflank the hird of hurds of GNUs that will soon trample you.
silly, silly troll. You could really teach ideut blah1394@hotmail.com a few lessons about steadfast persistence. You definitely make a much better "ideut".
-castlan
But so what, it's not like I have a life at this very moment. So I've waited a business week, can you continue this conversation yet?
Any _real_ troll worth his salt would not surrender so easily. Any respectable conversant would realize when they were mistaken, and submit with honor. Only sneaky vermin such as yourself would scuttle off and pretend it was an act of generosity. That is not to say that you wouldn't be doing us all a favor by just going away, unfortunately, your kind tends to reinfest after the lights go out again.
So, step into the light. Are you a man, or are you a mouse? (Because you definitely aren't a troll. The billy goat would have easily kicked your ass.)
Perhaps you are correct. In this case, "Debian" is not so much an entity, as an umbrella for the maintainers who volunteer their time. If this is a problem, then the answer is to report the bug, so that the maintainer is aware of it. If the maintainer is unresponsive after a reasonable amount of time, then one can always package the newer version which fixes the bug, as per the directions in the Debian developers section. This fixes your immediate problem. To help the Debian comunity, raise the issue via the appropriate Debian mailing list, and volunteer your updated dpkg as a candidtate for a Non-Maintainer Upload (NMU).
I still feel that for packages I am aware of, bugfixes are considered important, and are usually timely, if not subject to "fix in 24 hrs or your money back!" If you disagree, there are always options. If you need such guarantees, you can always pay for Debian support. One such company is Progeny Linux who used to distribute a very useable GNOME centric distribution called Progeny Debian. I believe they still maintain it somewhat, though it never made it past the "Newton" release, and they recommend that users upgrade to the current "Woody" release of debian 3.0. *sigh*
I don't believe my post was flawless in any sense! Does that mean that it didn't have iny information worth reading? I am very dissapointed by your reaction here, especially the victim mentality. How did you not get a chance? Despite your fears to the contrary, you were not modded down. There was no summary judgement or execution by the Slashdot wing of the "Debian Community" You were hardly excluded, and just about every post with positive moderation was very fair and even, not rallying against any people expressing "counter-Debian" sentiments.
/. karma probably isn't as valuable as respect. :(
I really wish that I didn't see this post. Perhaps a negative moderation wouldn't have been uncalled for in this case, if it obscured this post. I suppose that is because I find
-castlan
While well thought out standards are a good thing, some standards are meant to be broken. Seeing as how the LSB came after the fact, nonconformity could hardly be considered an act of fragmenting Linux. That is not to say that standards are not a worthy goal. The issue here is that Debian is sticking to a standard that was well defined before the LSB was concieved, before the FHS was called the FHS. This publicly available standard predates the concept of Open Source. The Debian Policy Manual is what makes Debian a paragon of Free Software, of open practices, and a positive institution in general.
It seems the the LSB is less of a standard to aspire to, then a LCD (lowest Common Denominator). While interoperability with the LSB as stated is an important goal, that does not mean that extra functionality, non-standard enhancements, or even differing but equivalent mechanisms should be wholly disposed of. That would just prevent evolution, and advancing the state of the art.
You say that Debian should cast off Dpkg in favor of using RPMs internally. Does that mean that Red Hat should condemn and avoid all post 3.05 RPMS? While Red Hat uses a package format with the same name as the LSB packages format, they are distinct packages. There is nothing wrong with Red Hat improving their RPM package, which is distinct with LSB RPMs. As long as an avenue of interoperability with LSBs is maintained, then they are compliant. Likewise with Debian. You said that Debian should quit dpkgs and work to improve RPMs. That would be of absolutely no benefit, because even if RPMs grew to be feature compatible with currrent dpkgs, those RPMs wouldn't be LSB RPMs.
Perhaps Debian dpkgs contain control information above and beyond that specified by the LSB. Are you suggesting that Debian cut off its left hand to be more conformant? As long as Debian can use alien to produce LSB RPMs (that would be missing the enhanced control info) then there is no reason to use RPMs internally. And just because alien can process LSB RPMs into less capable dpkgs doesn't mean that those RPMs should be preferred over less restrictive dpkgs.
Hopefully you can see that debian using dpkgs are a good thing, and have no downside as long as there is still an avenue for LSB RPM interoperability. But since the LSB mandates RPM, the Debian Policy Manual cannot incorporate the LSB wholesale.
Just a few more minor points.
I still stand by my statement that raw
Also, at no point did I say "APT packages". As I stated a few paragraphs ago, dpkgs currently are more expressive than LSB RPMS, so they would be preferred. I said
In other words, the 3.05 RPM of Red Penguin's PPPoE is less valueable to a Debian system then a current DPKG version. This RP-PPPoE is readily available in the standard Debian repostory, so rather than installing an unverified or out of date version via dpkg -i, it would be best to use the standard
In contrast, it seems that RPMs are more "network aware" than DPKGs. One cannot simply #dpkg -i http://127.0.0.1/distro/rp-pppoe.dpkg as you can with RPMs. DPKGs are an implementation of the worse-is-better philosophy, completely depending on an external transport mechanism like APT, so that each can focus on their specialized strengths more efficiently, with less complexity. I guess that RPMs are trying to be all-in-one integrated solutions. the existense on your repository seems to rather clearly express how good RPMs handle that. I must admit, I was not aware that APT/RPMs were common just yet. I just knew that some Brazillian Distro (connectiva?) had developed them, and they had seemed to fall behind in APT development. What shortcomings do you see in uRPMi that APT/RPM handles better?
Have you checked the alien maintainers web site? He has a fairly thourough comparison of DPKG, RPM and TGZ(with slackware control info). Going solely by the list of features, it seems that perhaps it would be less work to add Red Hat RPM's good features into DPKG. Though I still wouldn't want the LSB updated to this new DPKG+RPM format. The value of RPM 3.05 is that it is unambiguous, being fully defined and specified in Maximum RPM, and so there should be no reason why any arbitrary OS couldn't maintain interoperability with it.
Down With RED HAT, DEBIAN FOREVER!!!!
j/k,
-castlan
Alright, so you are at 50 karma, does that really mean you should post distorted rhetoric? I guess what I want to know is, do you believe half of what you have been posting in this cluster of threads? And did you really gain all of your karma points posting like this, or did you flip the troll flux capacitor when you reached 50? If it is the former, then I guess that you are the best argument for raising the Karma cap that I've recently seen.
Just various points, this isn't a zero-sum game. Macs only compete with systems providers in a general sense, but this is not strict competition, as there is not 1:1::human:computer ratio. Macs don't compete with Linux or Windows in any real sense, as Linux runs on Mac hardware, which is where Apple makes its money. Windows competes even less, because it doesn't run on Mac Hardware. Apples biggest "competetors" are their own development, production and advertising costs, in trying to win back new hardware sales from previous customers.
Apple and Linux need to cooperate... not against Windows, but for the advancement of consumer level computing for all. Macintosh has significantly developed the modern WIMP interface, the Windows 95 interface, and the KDE interface. This is already accounting for the invention of the foundation technologies at Palo Alto Research Center. If Apple (burned/fell-from-earth) then Linux developments in a desktop capacity would be seriously harmed, as the GUI would be locked until a later generation invents the feasible post WIMP GUI. This will take much too long without Apple's guidance, especially if we look to Microsoft for guidance. (Bob 2K? Can't wait!) Note that this is completely ignoring all direct MkLinux development, and lots of other Linux-indirect Unix development from before Linux's conception to modern day work.
Can Apple make their own way? They've been dying longer than Linux had been Buzzing. It looks to me like Apple's great fall is really just a LEOrbit. In another post you say same nonsense about Linus not support Apple. Apple already played the Linux game. They switched MkLinux for MkBSD/Lites server, so that they can restrict their system... almost like a Real UNIX, except that it still qualifies as Open Source.
Speaking of Real UNIX, how do you feel about them Unices as an OS? "In fact, I'd say I like the OS less because it's even more restrictive than Windows is (you have to buy very specific hardware, all approved by , and most of it overly expensive). I see no justification or need for cooperation between Linux developers and Apple." Care to replace all instances of Apple with NeXT? Okay, then how about any other Unix vendor?As for justification, it is the same with Linux as with with any other Unix. It's called the Portable Operating System Exchange standard, and it is the only RMS independant reason that Linux exists. While I have many harsh sentiments towards Jobs, many people would rather sit with him then Stallman - more flashy, less preachy.
Is Jobs and Co. capable of making their own way? I dunno, in a commercial sense, which Linux developer - hell, which handfull of Linux Resellers are doing better than Apple?
Hey Max, keep trolling, cuz you sure got my goat tonight. Now I'm gonna count sheep instead.
-castlan
Before I respond, what I really want to know is, does anybody know what ever came of the project to implement the Mac OS X GUI in x86? I know there was a project on sourceforge called achelous, but that hasn't been updated in quite some time. Does anybody have any information here? DisplayPDF and Quartz would be quite nice.
One point that seems to have been overlooked is that Mac OS X is theoretically more portable than FreeBSD or Linux. See, Mac OS X run on Darwin which is hosted on an implementation of the first generation Mach Microkernel. The Mach subsystem really isn't fully utilized, as both MkLinux and Darwin only run as single servers, neglecting the promise of microkernel technology. But the advantage that wasn't completely wasted was the hardware abstraction. Back when Linux was pre 2.0, the criticism was that Linux wasn't portable. Really it wasn't, but that didn't much matter if each implementation presented the same APIs, because then they could be interchangeable.
Back to the point, while Mach wasn't ported quite as widely as NetBSD or subsequently Linux, it was ported to at least PPC and x86. Running on Single servers running over Mach, Higher level services are really quite abstracted from the hardware - I'm not even sure that endianness should be an issue in this environment. So complexity (which already exists in abundance, from Mach-BSD-Quartz to Carbon/Cocoa/ClassicEmu) isn't significantly increased. In fact, the Mach-O binary format could fairly easily use Fat Binaries for everything, which means there is even less potential complexity to manage. Fat binaries have been extensively used in the past, both in 68k/PPC on classic, and 68k/x86/more on NeXTs yellowbox/cocoa environment. As for Mac OS X itself, in addition to your other arguments, I don't see how this could be a bad thing.
As gwernol already pointed out, just about all of the problems you pointed out could be solved by supporting Mac OS X-x86 only on Apple branded hardware. This would readily solve the basic driver problem, by defiing a known quantity. If a driver will work on Mach, then it should probably be independant of hardware platform, based on Mach's claim of true portability. (This is probably giving too much benefit of the doubt.) Then there could be an Apple certified hardware list, which should indicate compatibility on both platforms.
More of benefit to the x86 architecture in general, this would be the perfect excuse for Apple to introduce an x86 PC using Open Firmware, destroying reliance on the damned archaic IBM-refuse/early-Compaq-era PC BIOS forever! I'd gladly buy one of these to forget about all of the crufty limitations and hackish workarounds carried from the PC-XT et al. It should be fairly reasonable in price, as they wouldn't be integrating a Unifed Memory Architecture integrated into the graphics hardware like SGI did with their PROM based Visual Workstation series (which blew crude PC BIOSes away). It would be bringing a common standard shared by Sun and Apple to the common PC, increasing flexibility and robustness, from booting to remote administration, even over a serial port. I'd buy one of these in a heartbeat. (BTW, IBM didn't much care for the IBM PC, so it didn't care to expend to effort to pursue Compaq. Apple most definitely would not let any would-be Compaq get away with that, as is proved when {Sinclair?} tried the same thing - and don't forget about E-machines.)
The real danger in all of this, after all of the hyped benchmarking nonsense, would be if Mac OS X running on Apple x86s turned out to be tangibly more performant than on Macintoshes. If the Macs weren't indisputably the higher-end professional choice, it would impact the company. This would cause Apple to bleed money, as Mac Hardware sales would drop dramatically in light of this. It is a distinct possibility, when you consider that Mac OS X is very heavy on graphics useage. Graphics acceleration was very primitive on the Macintosh platform. In true chicken-and-egg fashion, it is likewise on classic Mac OS, and still lagging on Mac OS X. The much more mature transform and lighting capable hardware running on more finely tuned and fully enabled AGP 4x chipsets could have a significant impact on user responsiveness and percieved GUI performance. Additionally, the clock speeds and thoroughput on x86 machines are much higher, on CPUs, but more significantly on the system bus and especially in the memory subsystem. Another consideration is that Mach projects have had considerable development on x86, so it might possibly perform better then on PPC. These combined could show real impact on general system performance.
This is why emulation would be a Good Thing. The Red Box (hey, lets call it the Caffeine Windows API. Red Box was removed from Rhapsody, but it is viable on x86, especially since OpenStep ran on Windows. If not, Apple could always buy Caffeine from Virtual PC, SoftWindows, VmWare or even BOCHS--making a "Red BOCHS") would be another layer of overhead to slow down the system. More interestingly and effectively, Apple could provide a Carbon/Blue Box element to Mac OS X-x86. If some standard Carbon functionality was required by the base system, as it is on PPC, then the x86 platform could be hobbled as much as needed, while the value of the system would increase significantly. Fat Mach-O binaries could be universally portable between x86 and PPC, for ease of commercial software software distribution (shelf space) and support. The masses could see exactly how Microsoft Office apps are better on Mac OS then on Windows, and Mac OS X would finally gain a glut of gaming software.
I knew Mono was supposed to be highly contagious, but I didn't think it could jump species! That's what happened with AIDS, in other species (like simians-SIV*, bovines-BIV** and especially felines-FIV) it was harmless, but when it jumped to humans it became deadly. Does this have something to do with the Viral nature of the GPL? I guess Microsoft knew what they were talking about after all. Poor Gnomes... that's probably why you can't keep them as pets. Same thing with penguins at the South Pole - you can't get too close to them or they will get sick and die because their immune systems aren't as strong as ours. :(
I don't understand why anyone at the Register would show any sympathy for any of this. I'll bet they're happy about all of this misery. From what I understand, they're a morbid bunch of vultures over there!
* Not sure about Ximians and XIV, though I think that they were the first to develop Mono.
** I understand that Bovine cracked DES. I'm not sure how that compares to other viruses, but it sounds just awful.
-castlan
*** What are you looking for, I didn't use 3 asterisks anywhere in my post! Get out of here! I said SCAT! Shoo! Run along.****
**** Alright, if you really need more information of how FIV might have jumped to humans, you might want to look here
The potential of "Many eyes make bugs shallow" only applies to unit or even component testing, which can be fairly effective if there are enough well defined black boxes. The trouble comes when the white boxes are large, and system testing requires skilled and dedicated eyes.
As for Sardonix, how fine grained is their code auditing credit system? As I previously stated, does a fairly trivial component rate the same as an involved Mozilla audit? Can audits with a white box be distinguished from an entire system audit?
-castlan
Your general point is well taken, but that hardly makes this article a waste of time. Security is still more of an art than an exact science, which makes skilled administrators more valuable than any general distribution of an OS. While the article could have put more emphasis on this point, it does do a service in rasing awareness of this issue, for further research, and while not advancing the state of the art, perhaps it has helped contribute to the state of the science.
As for being a waste of _your_ time, that is quite likely if you are already an administrator worth your salt. In contrast, it is a potentially very important article if you happen to be a salty old administrator who distrusts non-commercial software.
-castlan
Irix tends to use /etc for binaries that Linux would put in /sbin. Filesystems are fairly arbitrary and cosmetic, so I don't think that filesystem tree layout is a good way to determine Unix lineage. The FHS project is a literal example of this, as many Linux Distros shuffled file layout to gain conformance. Most Unices use BSD sockets, including Linux, even while other parts may be SVR3 derived. SVR5 is arguably BSD derived as well, or at least subject to cross-pollination.
Your post seems at least misguided, and inappropriately antagonistic. There may be facts of which you are not aware. Of course, before you go quoting me, research the facts yourself, as I am pulling the SVR3 and SVR5 references from out of my ass. I apologize for using "facts" that are likely distorted.
So registering with this site allows a record of your auditing ability. I wonder how this project would compare someone who autited a simple program like test.c versus say Mozilla running on QNX.
-castlan
Your journal did not llow me to respond, so I had to post here to communicate with you. Since this discussion is "illicit" (offtopic) I am more concerned with raising issues than presenting a clear and concise argument. Please keep that in mind.
I do not disagree with the basic argument of your journal entry, but with your first assertion, regarding the definition of the term piracy.
Piracy is the boldly commited illegal act of violent misappropriation of goods or property, as in robbery. Robbery, a public act, when commited in transit over distribution channels, originally over the high seas, is piracy, though it can also apply to hijacking an airplane, or carjacking a delivery truck. The violence of robbery is enough to demonize it, but the large scale of violence makes it a more effective term than "software robery."
"Software piracy" is a misnomer, as is "software theft". Your arguments apply to the phrase software theft, which would be individual acts or crimes. The term software piracy leverages a loaded word which is more damning than simple theft, as piracy alludes to a violent large scale operation, akin to "organized crime" taking place over unpopulated areas such as the open ocean, or as it were, the Internet.
"Software theft" really amounts to unauthorized reproduction of information media. It seems the closest analog of this behaivor before the Internet became a pubic medium would be linked to the behaivor allowed by the Gutenberg Press - copying the Bible for mass distribution against the will of the "catholic" church, which restricted biblical access to ordained priests, so as to preserve their power structure.
This metaphor is not quite correct either, because there is a differnce between the archaic church as it existed centuries ago, and the modern day entertainment media production and distribution houses. This differnce is admittedly ideological, and not as subject to linguistic corruption. I'd say it falls somewhere in the spectrum of the ideologies of Capitalism versus Communism (economically, not with respect to practices of governance.) In contrast, the organized church did use this restriction as an improper form of goernance.
Another interesting attempt at demonizing unauthorized media distribution is the term bootlegging as applied to software. This term seems more accurate than "software piracy" especially in light of your journal post, as bootlegging doesn't involve embezzlement or theft(preventing useage by the rightful owner) but smuggling or illegal distribution. Bootlegging is also not as associated with violent behaivor, so wasn't as succesful (sensational) a term as was piracy. Bootlegging is a bit too crude of a term, as software bootlegging deserves a more refined term. The software itself is not contraband, as was prohibition era alcohol. The question is whether "bootlegging" is based on the act of possessing an illict substance with transportation being incidental, or illegal transportation with possesion being incidental. This might be considered in light of how in some States* alcohol is/was legal to possess for personal use, but not to transport/sell. Similarly in some places alocohol consumption wasn't criminal, just possesion. Both of these two situations seem engineered to "grandfather" those who had obtained alcohol prior to it becoming illicit, but to dry out future uses of alcohol.
One last interesting phrase to consider is "pirate radio". In contrast to using a legal medium to illegally distribute, this refers to illegally using a medium to distribute otherwise legal material. This would illustrate that the term "piracy" is far overused, in danger of corruption beyond resonable definition, which is unfortunate considering the source of the corruption. Being a natural language, useage determines the definition of words, published dictionaries are more akin to surveys then definitive useage manuals. The benefit of useing a natural language over a synthetic language, is the inherent flexibility makes it powerful. The problem arises when mass media uses its power to derail a language by propogating contrary or distorted definitions. The end result is the worst kind of synthetic language, because the expressive power is deliberately crippled with regard to issues that the media house has a vested interest in. In this regard, the insidious corruption of language (piracy, hacking, free, communist, punk, nigger, holocaust, civil disobediance, liberal, and just about every other "loaded" word you can think of) is at best unfortunate, and at worst just as bad as the orignial "catholic" church restricting mass reproduction of the Bible in order to opress civilization.
Slashdot Moderators: If you have read this far, but were offended, then you at least found this post interesting. So if you can't think of a response, perhaps you should moderate this as interesting so that another may see it and post an appropriately damning response. If you mark this as offtopic despite my warning in the title, then you are likely doing the community a disservice. If you feel this is simply a troll with no redeeming content, then moderate it as a troll unworthy of public resonse. I don't think "Insightful" would be appropriate for this post.