This is generally true except for the fact that Adobe products, and in fact just about every graphics program I've ever seen (INCLUDING the vector-based ones) use bitmap-based drop shadows.
I won't get into the math of it, but suffice it to say that it's computationally intensive to do drop shadows of a large scale. This can be sped up by taking more space.
You're right, the *incredible* architectural choice of ditching the design for a 64-bit design.
Both Intel and AMD are going to ditch their current designs for the 64-bit Itanium/Sledgehammer series. And if you think the "current designs" have ANYTHING to do with upcoming backwards compatibility, you're dead wrong. Intel (and AMD for that matter) are milking the most out of their existing systems. But running an app in 32-bit mode on a 64-bit processor is generally a matter of some sign extension hardware on the processor. I don't think the same pipelining and branch prediction hardware will be in the cpu, if only because there are going to be more steps in the pipeline.
Intel DID make an architectural choice for a short-term gain. In this case, the gain is market share. The market has equalled, in their mind, clock speed and performance.
Okay, but here's the question
Using your muscles helps improve bone density. This is why weight lifting helps to strengthen your bones.
Is the vibration *per se* causing the bones to grow, or is it the thousands of miniscule muscular movments a sheep would have to make to remain steady on a vibrating platform that is causing the bones to grow?
I'm not being argumentative, I'm just curious, because if it *is* the muscle movements that help strenghten the bone, you wouldn't need a vibrating platform, you'd just need a few electrodes implanted in key places and twitch all night;)
Just a correction: that's A/UX, not AIX. AIX is IBM's commercial UNIX.
The kernel for OS X isn't a UNIX(TM) kernel, it's Mach, developed at Carnegie Mellon. BSD is implemented as a userland server atop the microkernel (much like OSF/1). Theoretically, if anyone deigned to write Win32 as a subsystem atop Mach, you could have Windows applications running on top of the server.
I'm not sure -- does the Classic environment run on top of BSD on top of Mach, or does it run directly on top of Mach?
My understanding is Mandrake 8.0 used ALSA exclusively. I use the Maestro 2 chipset (it's a crappy no-name laptop), and it didn't seem to multiplex sounds at all. Hence I use artsd. Am I completely on crack, and is there a definitive way to test if the ESS Maestro 2 is capable of/currently wavetable mixing via ALSA?
Re:What are the weakest parts of Linux?
on
IBM Wants Linux
·
· Score: 0
O(10)years ago, the folks doing 386BSD (I believe -- someone correct me if I'm wrong) -- were embroiled in a lawsuit with AT&T over copyright to some of the source code. The BSD folks lost, had to strip out the AT&T code, and the result is 4.4-Lite, which is what you see in *BSD today.
Because of the lawsuit, development kind of stalled, people were sort of scared away, choose your expectation. Partially because of the lack of developers, development schedules slowed somewhat and priority was shifted toward efficiency, not user-friendliness. The user base grew more slowly and BSD became more of a niche system.
BSD didn't have many commercial backers. Flame Red Hat all you want, but in addition to their distro and the services they provide, they also employ kernel hackers like Alan Cox. Development moves faster when you're paid to do it. The closest BSD based commercial distribution is BSDI, and they charge O($1000) for their product. Such prices didn't really contribute to popularity either.
A lot of the lack of commercial popularity also has to do with design methodologies. FreeBSD has been marketed, especially after the merger with BSDI. NetBSD, on the other hand, is pretty much a proof-of-concept operating system ("hey, we can run on THIS"). OpenBSD is concerned with security, but security and usability are in many cases mutually exclusive. This would relegate OpenBSD to the router and server market (where it does fairly well, I hear).
Part of it has to do with business methods as well. Lots of businesses like constant support. FreeBSD-core, prior to its merger with BSDI/Walnut Creek, didn't have a high-profile company supporting it like Red Hat, Mandrake or SuSe. There is no outsourcing of BSD support like Linuxcare. OpenBSD and NetBSD have no armies of corporate support. I guess you could buy Theo De Raadt off fairly cheaply, but even then he's only one man and he can't be in more than one place or work on too many tasks at one time (sources tell me it's because Theo, like OpenBSD, doesn't have MP support)
That having been said, BSD has a lot of behind-the-scenes work. Hotmail and Yahoo both use FreeBSD. BSD is in many of the plug-and-chug appliance servers (like the Whistle Interjet). OpenBSD is in use in some smaller-scale routers. And of course, we can't forget the BSD giants, NeXT, and now Apple/NeXT, which use BSD based operating systems. OS X, in particular, uses FreeBSD as its reference for Darwin (which IS available for Intel, if you want to try it out). It's not marketed as such, really, because Apple likes to hide internals and promote shiny happy GUI -- but rest assured, it's there (even if it's BSD/mach rather than BSD proper).
Re:What are the weakest parts of Linux?
on
IBM Wants Linux
·
· Score: 0
My imperfect memory tells me STREAMS was indended to be a successor to Berkely Sockets, using a transport mechanism called TLI rathern than the OSI model (TCP/IP, etc...)
It's really a System V thing... It was deemed Sexy by AT&T because it allowed a unified driver API for network drivers, device drivers, ptys, etc.
More info at http://www.gcom.com/home/linux/lis/index.html .
You can find more at.
If you haven't seen the double standard in practice, take a look below:
BEGIN MOCK BLOCK
Well, as a SysAdmin who manages 50 Windows 2000 Datacenter servers and 20 Solaris servers I can try to offer some info.
As has been written in a couple of posts already, Windows 2000 Datacenter is designed to run on enterprise-level hardware. The bonus is that since the OS and hardware all come from IBM, there is a single point of contact for those problems. There are some really cool things that separate Windows 2000 Datacenter from other UNIX's:
Most of the critical OS functions can be controlled via the MMC interface.
Unlike other flavours of UNIX, Windows 2000 Datacenter does not use flat files to define parameters for daemons. Windows 2000 Datacenter has all the relevant information stored in an internal database (The Registry).
Windows 2000 Datacenter ships with a journaled file system and file systems can be grown on the fly.
Windows 2000 Datacenter gives way more control over disk management than other flavours of UNIX. It is easy to implement the various types of RAID. Windows 2000 Datacenter also lets you control where certain files can be physically located on your disk, and during off-peak hours the system can move files around to re-organize the disks.
It is trivial to create a complete image of the system on a bootable tape, so disaster recovery is a snap.
There are some downsides to Windows 2000 Datacenter:
Windows 2000 Datacenter takes >5 minutes to boot.
If the Registry gets corrupted, your system can be toast.
Sometimes it is necessary to modify the Registry directly, and this can be a bit risky (see above)
Third-party support for Windows 2000 Datacenter is sketchy. It is better to use Microsoft applications where possible.
END MOCK BLOCK
It seems that the stuff we mock in one OS we praise in another...
Re:What are the weakest parts of Linux?
on
IBM Wants Linux
·
· Score: -1
No one modded me down. A long long time ago, when slashdot had just implemented metamoderation, I got "bitchslapped" for modding up Meept!!/The Glorioue Meept!! Apparently I was feeding a troll, even though it was very clear that Meept!! was no troll, but rather an avante garde artist of a strange dadaist caliber.
I moderated what I thought was funny, what I thought was insightful, etc. That's what I thought the 'funny, insightful', etc. part of moderation was. The moderator makes the decision.
I was trying to stem the wave of karma whores by voting my conscience. Apparently, for a moderator's moderation to be considered quality, you gotta go with what all the other moderators and metamoderators think. Karma whoring continues, dissenting opinions are bitchslapped.
So... you 'feed the troll', everything you post goes to -1. Such is life.
This isn't a sob story. I don't complain. I post my posts, and if anyone think they're interesting and is reading at -1, then they mod it up. If you miss what I have to say, then too bad for them;-)
But the odd thing is... NOW... a lot of people miss Meept!! and Oog the Open Source Caveman. The grass is always greener on the other side, eh? I'm just waiting for the circle to close, Slashdot renames itself BACK to "Chips N' Dips", and we get the next wave: Signal 11 Nostalgia.
-- moi
P.S. I still think Meept!! was CmdrTaco under the influence;-)
P.P.S. Does anyone remember the Slashdot trading cards, where Meept!! was Bill Gates?
Re:What are the weakest parts of Linux?
on
IBM Wants Linux
·
· Score: 5, Informative
Linux doesn't have STREAMS or TLI support; this means that device drivers are significantly different from the rest of the (commercial) UNIX(TM) world. There are third party patches, but STREAMS will never make it into the source tree, because Linus has explicitly rejected it.
Linux doesn't (AFAIK -- correct me if I am wrong!) have run-time tunable quanta (timeslices) for scheduling. The 'jiffy' (minimum unit of time measurement) is still tied to a 100 Hz clock (except on Alpha, where it is 1024Hz). Other run-time tunable parameters include features like page replacement algorithms (when to replace pages in memory). Solaris has a 'two-handed clock sweep' algorithm, and runtime tunable parameters include the 'spread' between the 'hands' and the speed of the 'clock rotation' (cf. Stallings, William. Operating Systems)
This isn't a linux problem per se, but the gcc toolkit doesn't make the best object code on any target other than x86. That's why solaris distributes gcc with solaris8 but remains confident you're going to get/opt/SUNWpro compilers. Same goes with Tru64, etc. etc. Since most commercial Unices run on non-Intel platforms (Solaris, AIX, Tru64, Mac OS X, HP-UX, IRIX) it generally means that you're not going to get the best executables if you use gcc (exceptions include Mac OS X)
As others have said, NUMA doesn't scale well. Linux proper doesn't have good 'processor affinity' (ie, tying a process to a specific processor).
Linux doesn't have good capabilities support or support for ACLs. While some capabilities exist (eg, CAP_DAC_OVERRIDE for embedded systems without filesystems, or the capability to bind to ports < 1024 without being root), a lot of big-iron systems need capabilities more approaching that of VMS or Windows NT kernel (note I said kernel, not Win32). You can get some capabilities with LIDS, but that's generally related to the CAP_DAC and CAP_MAC set, without much more. As for ACLs, you *can* find some patches, but they're most certainly not standard. Moreover, VFS isn't quite set for things like LVM, much less filesystem plug-ins (witness the hullaballoo in putting ReiserFS in the system because it didn't conform to VFS conventions).
Linux failover and high-availability generally applies to clustering solutions; I've yet to see things like hot-swappable CPUs or multiple backplane support in Linux.
This isn't to say Linux isn't great. I use it along with OpenStep and FreeBSD as my main operating systems. Most people don't need the above, or the penalties for uniprocessor x86 hardware are high (who wants STREAMS on an IBM PC-compatible?). But for commercial UNIX (TM), the above is pretty relied upon.
Kidding aside, has anyone studied the effect of 'educational' games on the brain? I wonder if someone made a FPS of Number Crunchers, would the math skills learned cancel out the alleged damage?
That's actually *very* cool. However, I'll stick by my belief that it won't be integrated into the main source tree, esp. when it's something that affects so many low-level design decisions (e.g, ptys, network device drivers, etc.)
Moreover, tracking kernels and patches can lead to the patches and kernels getting out of sync (supermount anyone?)
But yeah, it's pretty cool...I like how they even ship it compiled (good for distros)
Do you have any proof of that? I'd like to see it. Given a property dispute, it would be safe to say that "one's word vs. the other" would yield in favor of the property owner. In other words, even if Mr. Foo LET you borrow his car, if he later accuses you of stealing it, he's entitled to do so if he hasn't signed a contract (and consideration changed hands). And you lose.
This is why we should always have everything in paper, and run by a lawyer.:)
I've made some suggestions and I'd like to see them come to fruition.
As a longtime Mandrake user, one of the major problems I have with them is their stalwart insistence on including the most cutting edge software with *all* options installed, and then the inconsistencies begin to flow.
Good examples include the following:
* By default on 8.0, iptables is installed (and not ipchains). portsentry is installed, but its default ${KILL_ROUTE} is to use ipchains. A minor, one line fix to portsentry.conf is all that is needed.
* Speaking of iptables, it's safe to say that one shouldn't include all options for iptables in a generic kernel. Some of the options aren't compatible with each other. Some of the options are from patches for various versions of the kernel. ipchains support and ipfwadm support are compiled in as modules, but the default ipchains package is, i think, statically linked, because it doesn't work when ipchains.o is loaded anyway.
* Modules for devices like/dev/rtc,/dev/nvram or the major/minor 36 (routing devices) are standard and configured, but the devices aren't made with default MAKEDEV. This isn't really critical to the system, but it is messy AFAIK.
* I swear, some of the patches are doing crazy things with the spinlocks. On 7.2 and above, when I compiled the system with USB support, 'apm suspend system' would freeze. This would make going into PhoenixBIOS hibernation (which worked with 7.0/7.1, and redhat) freeze as well. Without USB compiled in, everything is dandy.
* Various minutia: when one installs VNCServer, it prompts for a password from stdin, but by default, Aurora is installed, thus capturing keyboard and mouse input. Thus the system blocks on input.
This is NOT me bashing Mandrake. I love mandrake. Repeat: I LOVE MANDRAKE. I think it's very customizable, I think it's very easy for the newbie but quite configurable for the non-newbie (it should be noted that I was able to solve all of the above problems with a little bit of tinkering). It's just that these little blemishes should be addressed on minor point revisions (most weren't between major point revisions 7.2->8.0).
As many have stated, GNU utilities are nothing new to SCO (cf. Skunkware). For those who aren't quite knowledgeable of SVR5, there *are* serious advantages to running a UNIX(tm) kernel as opposed to Linux. Not all of these are hardware related.
UNIX(tm) has TLI and STREAMS support. Linus has explicitly decided that TLI is to be passed over in favor of sockets, and STREAMS isn't to be supported at all (leading to some hackneyed workarounds regarding ptys). So for those of you who will say "big deal, SCO kernel has some better hardware/threading/${FOO}, we'll develop the drivers/mutexes/${BAR} for it," there are some things that will never, ever be put into the main source tree due to administrative decision.
Yes, TLI and STREAMS have inherent performance penalties, but they provide a much more sane API for driver development. Hardware today is fast enough to handle a small performance penalty that Linus' 386 could not.
In short: This is a good thing, because it presents a system which runs on x86 which has significant DESIGN differences. Someone has opted for the other fork of the tradeoff branch; assuming the standard utilies and libc are in sync with Linux's GNU toolkit, this means that the same application can take advantage of two different paradigms for two different situations (BSD/sockets vs TLI+STREAMS). I guess this is like the BSD/a.out vs. Linux/ELF scenario of a couple years back. Each system has its pros and cons, programs are source compatible to work with either.
Now that *that* little ruckus has been resolved...
So this really is nothing new. UNIX kernel, (optional) GNU utilities (e.g, Skunkware). Most big UNIX vendors distributed UNIX utilities (Sun, SCO/Caldera,etc) with GNU utils. Hell, NeXT made gcc their default compiler (and charged thousands of dollars for it. Ha!). And it's a good thing. I'm glad.
As I said before (http://slashdot.org/comments.pl?sid=01/08/03/1935 231&cid=71), the main advantage of Be in the handheld market is that it doesn't have to worry about barriers to entry in the desktop/server market. Be didn't have a chance in the desktop market, because it would have to be compatible with Windows and everything Windows is ostensibly backwards/forwards compatible with. Playing catch-up like that is pretty hard (in fact, I'm rather surprised that Linux and other free UNIX is doing as well as it is).
However, in the embedded/handheld market, there are no barriers to entry. Because of the small footprint, one can get away with making a small, fast, modular OS.
Be's advantages are manifold. First and foremost, it is a low-latency (i shudder to say "real-time") operating system. The responsiveness needed makes Be perfect for handheld devices, where, for instance, one needs visual feedback from writing. God knows Graffiti always lags three or four strokes behind what I've written, and that makes any sort of complicated message writing substantially more difficult.
Be is also highly modular. It's doubtful whether or not the next generation of Palm would have sound; I'd imagine that the lower end models would not have sound, and the higher end models would double as an MP3 player, etc. By removing sound_server, one doesn't worry about breaking any tightly-coupled components, because there are no tightly-coupled components.
Tracker is a superior alternative to any sort of taskbar-based file navigation system (ie, Windows Explorer, KDE, GNOME, etc.). It's much more space-efficient and can neatly tuck itself out of the say (don't get me started on Windows CE's "autohide" feature, because it goes crazy whenever I tap a little too close to its threshold)
I don't, however, think that Be is going to have a future on the desktop. BeOS is a niche that can easily be filled by Linux (with appropriate latency patches) or Mac OS X (which has all the posixy CLI goodness). Flame me if you like, I bought Be versions 4, 4.5, and 5, and I have BeBoxen running, but it's simply not going to achieve World Domination(TM) or even Neighborhood Domination(TM), simply because of the barriers to entry. Corporations work along the path of least resistance. So do most developers, I might add.
An interesting idea for handhelds would be Mac OS X. Because it is a microkernel, it can be trimmed to fit certain handheld devices. Moreover, Aqua is also a sexy interface, and -- if you pare away the Blue Box cruft -- its operating environment can be very lean. (objective C has, IMO, much less overhead). I wouldn't be surprised if Steve Jobs makes a nice, translucent colored plastic, Aqua-in-your-face, Newton II. I say, more power too him. Hell, OPENSTEP used to run on Motorola 25/33Mhz processors (and sparc, and PA-RISC, and intel..). I don't see why it wouldn't run on a Motorola Dragonball processor, much less a mobile G4 processor. A NeXT/Mac OS X-based PDA is a pretty damn good idea, actually. I would not be surprised if it came out within the next three years.
Now that I think of it...
On a side note, if anyone is interested in carving up some NeXT hardware to make an OpenStep PDA, gimme an e-mail:) I've got cubes, slabs, turbo and regular, all mono.
It seems a lot of people here aren't reading the article. Going over the specifications, I'm noticing a few things:
Bear in mind I'm not the most knowledgeable person in programming, so if I *am* wrong, don't just mod me down and insult me. Point out where, and I'll learn from the experience.
It seems from first glance that this language shares many superficial characteristics with Objective-C. No multiple inheritance, no operator overloading, etc.) It also seems that the author's rant on definition vs. declaration seems to be an attack on C++ prototyping in specific, but Objective-C seems to do the job quite well (with @interface versus @implementation blocks).
It also seems, from cursory surface examination, that D's "REAL typedefs" seem to resemble Objective-C's typedef'ing of the 'id' primitive -- which incidentally, does real dynamic binding on method return values. you return 'id' but based on whatever happens in the method, you can assign an int, long, whatever handle to it.
I don't like how all class copies are by reference. There are certain instances where a deep copy is required...
After all the ranting and raving about how operator overloading is worthless, the string (or should i say, "dynamic array") semantics seem to already have their operators overloaded, as given in the example code at http://www.digitalmars.com/d/arrays.html.
#import versus #include (where the included file has #ifndef __THIS_FILE_H...) was already addressed in Objective C, however the GNU compiler for Objective C is braindead and warns you unless you have -Wno-import (I think) set.
The inclusion of complex data types as primitives could easily be solved with a standard class library. The same applies for strings, etc. Yet D doesn't have an STL.
I'm all for new languages, and I wish the author success. Nor do I think the language lacks good points. I would, however, like the author to explain why he chose these courses of action, or differentiate more between D and something like Objective-C, or otherwise cluefy me.
Re:Mob developed software - hmmmm...
on
Mob Software
·
· Score: -1
/* don oh my god you're not funny */
I never claimed I was funny. I just wanted something that was less unfunny than the slew of obvious "this is a patch you can't refuse" jokes.
Re:Mob developed software - hmmmm...
on
Mob Software
·
· Score: 2, Interesting
Because absolutely *everyone* here has either:
1) thought of the obvious Mafia jokes, or
2) bitched about how obvious the Mafia joke is and how it shouldn't be considered funny,
allow me, while ostensibly making a 'mob' joke, to bring a new and fresh topic of conversation to the table:
Who would win in a fight?
a) Don Corleone (young or old; your choice)
b) Don Juan
c) Don Quixote
d) Don Ho
e) Don Adams
f) Don Diego de la Vega
g) Don Knotts
h) Don Pablo
i) Donatello (artist)
j) Donatello (ninja turtle)
k) Don CowboyNeal
Slashdot Mirror
Dare I say it?
/dev/mark
chmod 0666
You can laugh, but that's actually not a bad idea based on the way that many page replacement algorithms work...
This is generally true except for the fact that Adobe products, and in fact just about every graphics program I've ever seen (INCLUDING the vector-based ones) use bitmap-based drop shadows.
I won't get into the math of it, but suffice it to say that it's computationally intensive to do drop shadows of a large scale. This can be sped up by taking more space.
You're right, the *incredible* architectural choice of ditching the design for a 64-bit design.
Both Intel and AMD are going to ditch their current designs for the 64-bit Itanium/Sledgehammer series. And if you think the "current designs" have ANYTHING to do with upcoming backwards compatibility, you're dead wrong. Intel (and AMD for that matter) are milking the most out of their existing systems. But running an app in 32-bit mode on a 64-bit processor is generally a matter of some sign extension hardware on the processor. I don't think the same pipelining and branch prediction hardware will be in the cpu, if only because there are going to be more steps in the pipeline.
Intel DID make an architectural choice for a short-term gain. In this case, the gain is market share. The market has equalled, in their mind, clock speed and performance.
"This article brought to you by THOMPSON'S TEETH:
The only teeth strong enough to eat OTHER TEETH."
/* Why were scientists looking to make sheep with bigger bones anyway? */
Osso Buco?
Okay, but here's the question
;)
Using your muscles helps improve bone density. This is why weight lifting helps to strengthen your bones.
Is the vibration *per se* causing the bones to grow, or is it the thousands of miniscule muscular movments a sheep would have to make to remain steady on a vibrating platform that is causing the bones to grow?
I'm not being argumentative, I'm just curious, because if it *is* the muscle movements that help strenghten the bone, you wouldn't need a vibrating platform, you'd just need a few electrodes implanted in key places and twitch all night
Just a correction: that's A/UX, not AIX. AIX is IBM's commercial UNIX.
The kernel for OS X isn't a UNIX(TM) kernel, it's Mach, developed at Carnegie Mellon. BSD is implemented as a userland server atop the microkernel (much like OSF/1). Theoretically, if anyone deigned to write Win32 as a subsystem atop Mach, you could have Windows applications running on top of the server.
I'm not sure -- does the Classic environment run on top of BSD on top of Mach, or does it run directly on top of Mach?
My understanding is Mandrake 8.0 used ALSA exclusively. I use the Maestro 2 chipset (it's a crappy no-name laptop), and it didn't seem to multiplex sounds at all. Hence I use artsd. Am I completely on crack, and is there a definitive way to test if the ESS Maestro 2 is capable of/currently wavetable mixing via ALSA?
O(10)years ago, the folks doing 386BSD (I believe -- someone correct me if I'm wrong) -- were embroiled in a lawsuit with AT&T over copyright to some of the source code. The BSD folks lost, had to strip out the AT&T code, and the result is 4.4-Lite, which is what you see in *BSD today.
Because of the lawsuit, development kind of stalled, people were sort of scared away, choose your expectation. Partially because of the lack of developers, development schedules slowed somewhat and priority was shifted toward efficiency, not user-friendliness. The user base grew more slowly and BSD became more of a niche system.
BSD didn't have many commercial backers. Flame Red Hat all you want, but in addition to their distro and the services they provide, they also employ kernel hackers like Alan Cox. Development moves faster when you're paid to do it. The closest BSD based commercial distribution is BSDI, and they charge O($1000) for their product. Such prices didn't really contribute to popularity either.
A lot of the lack of commercial popularity also has to do with design methodologies. FreeBSD has been marketed, especially after the merger with BSDI. NetBSD, on the other hand, is pretty much a proof-of-concept operating system ("hey, we can run on THIS"). OpenBSD is concerned with security, but security and usability are in many cases mutually exclusive. This would relegate OpenBSD to the router and server market (where it does fairly well, I hear).
Part of it has to do with business methods as well. Lots of businesses like constant support. FreeBSD-core, prior to its merger with BSDI/Walnut Creek, didn't have a high-profile company supporting it like Red Hat, Mandrake or SuSe. There is no outsourcing of BSD support like Linuxcare. OpenBSD and NetBSD have no armies of corporate support. I guess you could buy Theo De Raadt off fairly cheaply, but even then he's only one man and he can't be in more than one place or work on too many tasks at one time (sources tell me it's because Theo, like OpenBSD, doesn't have MP support)
That having been said, BSD has a lot of behind-the-scenes work. Hotmail and Yahoo both use FreeBSD. BSD is in many of the plug-and-chug appliance servers (like the Whistle Interjet). OpenBSD is in use in some smaller-scale routers. And of course, we can't forget the BSD giants, NeXT, and now Apple/NeXT, which use BSD based operating systems. OS X, in particular, uses FreeBSD as its reference for Darwin (which IS available for Intel, if you want to try it out). It's not marketed as such, really, because Apple likes to hide internals and promote shiny happy GUI -- but rest assured, it's there (even if it's BSD/mach rather than BSD proper).
My imperfect memory tells me STREAMS was indended to be a successor to Berkely Sockets, using a transport mechanism called TLI rathern than the OSI model (TCP/IP, etc...)
It's really a System V thing... It was deemed Sexy by AT&T because it allowed a unified driver API for network drivers, device drivers, ptys, etc.
More info at http://www.gcom.com/home/linux/lis/index.html .
You can find more at.
Oh shit! Linux and "a school in Colorado" in the same story?
Someone had better hide this from Jon Katz... :-)
While Ug and Glug were discussing the finer points of GUI design, I'm sure Oog the Open Source Caveman was deriding them :)
If you haven't seen the double standard in practice, take a look below:
BEGIN MOCK BLOCK
END MOCK BLOCKIt seems that the stuff we mock in one OS we praise in another...
No one modded me down. A long long time ago, when slashdot had just implemented metamoderation, I got "bitchslapped" for modding up Meept!!/The Glorioue Meept!! Apparently I was feeding a troll, even though it was very clear that Meept!! was no troll, but rather an avante garde artist of a strange dadaist caliber.
;-)
;-)
I moderated what I thought was funny, what I thought was insightful, etc. That's what I thought the 'funny, insightful', etc. part of moderation was. The moderator makes the decision.
I was trying to stem the wave of karma whores by voting my conscience. Apparently, for a moderator's moderation to be considered quality, you gotta go with what all the other moderators and metamoderators think. Karma whoring continues, dissenting opinions are bitchslapped.
So... you 'feed the troll', everything you post goes to -1. Such is life.
This isn't a sob story. I don't complain. I post my posts, and if anyone think they're interesting and is reading at -1, then they mod it up. If you miss what I have to say, then too bad for them
But the odd thing is... NOW... a lot of people miss Meept!! and Oog the Open Source Caveman. The grass is always greener on the other side, eh? I'm just waiting for the circle to close, Slashdot renames itself BACK to "Chips N' Dips", and we get the next wave: Signal 11 Nostalgia.
-- moi
P.S. I still think Meept!! was CmdrTaco under the influence
P.P.S. Does anyone remember the Slashdot trading cards, where Meept!! was Bill Gates?
Linux doesn't have STREAMS or TLI support; this means that device drivers are significantly different from the rest of the (commercial) UNIX(TM) world. There are third party patches, but STREAMS will never make it into the source tree, because Linus has explicitly rejected it.
Linux doesn't (AFAIK -- correct me if I am wrong!) have run-time tunable quanta (timeslices) for scheduling. The 'jiffy' (minimum unit of time measurement) is still tied to a 100 Hz clock (except on Alpha, where it is 1024Hz). Other run-time tunable parameters include features like page replacement algorithms (when to replace pages in memory). Solaris has a 'two-handed clock sweep' algorithm, and runtime tunable parameters include the 'spread' between the 'hands' and the speed of the 'clock rotation' (cf. Stallings, William. Operating Systems)
This isn't a linux problem per se, but the gcc toolkit doesn't make the best object code on any target other than x86. That's why solaris distributes gcc with solaris8 but remains confident you're going to get /opt/SUNWpro compilers. Same goes with Tru64, etc. etc. Since most commercial Unices run on non-Intel platforms (Solaris, AIX, Tru64, Mac OS X, HP-UX, IRIX) it generally means that you're not going to get the best executables if you use gcc (exceptions include Mac OS X)
As others have said, NUMA doesn't scale well. Linux proper doesn't have good 'processor affinity' (ie, tying a process to a specific processor).
Linux doesn't have good capabilities support or support for ACLs. While some capabilities exist (eg, CAP_DAC_OVERRIDE for embedded systems without filesystems, or the capability to bind to ports < 1024 without being root), a lot of big-iron systems need capabilities more approaching that of VMS or Windows NT kernel (note I said kernel, not Win32). You can get some capabilities with LIDS, but that's generally related to the CAP_DAC and CAP_MAC set, without much more. As for ACLs, you *can* find some patches, but they're most certainly not standard. Moreover, VFS isn't quite set for things like LVM, much less filesystem plug-ins (witness the hullaballoo in putting ReiserFS in the system because it didn't conform to VFS conventions).
Linux failover and high-availability generally applies to clustering solutions; I've yet to see things like hot-swappable CPUs or multiple backplane support in Linux.
This isn't to say Linux isn't great. I use it along with OpenStep and FreeBSD as my main operating systems. Most people don't need the above, or the penalties for uniprocessor x86 hardware are high (who wants STREAMS on an IBM PC-compatible?). But for commercial UNIX (TM), the above is pretty relied upon.
I used to play Oregon Trail a lot...
Now I know why I compulsively shoot buffalo!
Kidding aside, has anyone studied the effect of 'educational' games on the brain? I wonder if someone made a FPS of Number Crunchers, would the math skills learned cancel out the alleged damage?
That's actually *very* cool. However, I'll stick by my belief that it won't be integrated into the main source tree, esp. when it's something that affects so many low-level design decisions (e.g, ptys, network device drivers, etc.)
Moreover, tracking kernels and patches can lead to the patches and kernels getting out of sync (supermount anyone?)
But yeah, it's pretty cool...I like how they even ship it compiled (good for distros)
Do you have any proof of that? I'd like to see it. Given a property dispute, it would be safe to say that "one's word vs. the other" would yield in favor of the property owner. In other words, even if Mr. Foo LET you borrow his car, if he later accuses you of stealing it, he's entitled to do so if he hasn't signed a contract (and consideration changed hands). And you lose.
:)
This is why we should always have everything in paper, and run by a lawyer.
I've made some suggestions and I'd like to see them come to fruition.
/dev/rtc, /dev/nvram or the major/minor 36 (routing devices) are standard and configured, but the devices aren't made with default MAKEDEV. This isn't really critical to the system, but it is messy AFAIK.
As a longtime Mandrake user, one of the major problems I have with them is their stalwart insistence on including the most cutting edge software with *all* options installed, and then the inconsistencies begin to flow.
Good examples include the following:
* By default on 8.0, iptables is installed (and not ipchains). portsentry is installed, but its default ${KILL_ROUTE} is to use ipchains. A minor, one line fix to portsentry.conf is all that is needed.
* Speaking of iptables, it's safe to say that one shouldn't include all options for iptables in a generic kernel. Some of the options aren't compatible with each other. Some of the options are from patches for various versions of the kernel. ipchains support and ipfwadm support are compiled in as modules, but the default ipchains package is, i think, statically linked, because it doesn't work when ipchains.o is loaded anyway.
* Modules for devices like
* I swear, some of the patches are doing crazy things with the spinlocks. On 7.2 and above, when I compiled the system with USB support, 'apm suspend system' would freeze. This would make going into PhoenixBIOS hibernation (which worked with 7.0/7.1, and redhat) freeze as well. Without USB compiled in, everything is dandy.
* Various minutia: when one installs VNCServer, it prompts for a password from stdin, but by default, Aurora is installed, thus capturing keyboard and mouse input. Thus the system blocks on input.
This is NOT me bashing Mandrake. I love mandrake. Repeat: I LOVE MANDRAKE. I think it's very customizable, I think it's very easy for the newbie but quite configurable for the non-newbie (it should be noted that I was able to solve all of the above problems with a little bit of tinkering). It's just that these little blemishes should be addressed on minor point revisions (most weren't between major point revisions 7.2->8.0).
As many have stated, GNU utilities are nothing new to SCO (cf. Skunkware). For those who aren't quite knowledgeable of SVR5, there *are* serious advantages to running a UNIX(tm) kernel as opposed to Linux. Not all of these are hardware related.
UNIX(tm) has TLI and STREAMS support. Linus has explicitly decided that TLI is to be passed over in favor of sockets, and STREAMS isn't to be supported at all (leading to some hackneyed workarounds regarding ptys). So for those of you who will say "big deal, SCO kernel has some better hardware/threading/${FOO}, we'll develop the drivers/mutexes/${BAR} for it," there are some things that will never, ever be put into the main source tree due to administrative decision.
Yes, TLI and STREAMS have inherent performance penalties, but they provide a much more sane API for driver development. Hardware today is fast enough to handle a small performance penalty that Linus' 386 could not.
In short: This is a good thing, because it presents a system which runs on x86 which has significant DESIGN differences. Someone has opted for the other fork of the tradeoff branch; assuming the standard utilies and libc are in sync with Linux's GNU toolkit, this means that the same application can take advantage of two different paradigms for two different situations (BSD/sockets vs TLI+STREAMS). I guess this is like the BSD/a.out vs. Linux/ELF scenario of a couple years back. Each system has its pros and cons, programs are source compatible to work with either.
Now that *that* little ruckus has been resolved...
So this really is nothing new. UNIX kernel, (optional) GNU utilities (e.g, Skunkware). Most big UNIX vendors distributed UNIX utilities (Sun, SCO/Caldera,etc) with GNU utils. Hell, NeXT made gcc their default compiler (and charged thousands of dollars for it. Ha!). And it's a good thing. I'm glad.
As I said before (http://slashdot.org/comments.pl?sid=01/08/03/1935 231&cid=71), the main advantage of Be in the handheld market is that it doesn't have to worry about barriers to entry in the desktop/server market. Be didn't have a chance in the desktop market, because it would have to be compatible with Windows and everything Windows is ostensibly backwards/forwards compatible with. Playing catch-up like that is pretty hard (in fact, I'm rather surprised that Linux and other free UNIX is doing as well as it is).
:) I've got cubes, slabs, turbo and regular, all mono.
However, in the embedded/handheld market, there are no barriers to entry. Because of the small footprint, one can get away with making a small, fast, modular OS.
Be's advantages are manifold. First and foremost, it is a low-latency (i shudder to say "real-time") operating system. The responsiveness needed makes Be perfect for handheld devices, where, for instance, one needs visual feedback from writing. God knows Graffiti always lags three or four strokes behind what I've written, and that makes any sort of complicated message writing substantially more difficult.
Be is also highly modular. It's doubtful whether or not the next generation of Palm would have sound; I'd imagine that the lower end models would not have sound, and the higher end models would double as an MP3 player, etc. By removing sound_server, one doesn't worry about breaking any tightly-coupled components, because there are no tightly-coupled components.
Tracker is a superior alternative to any sort of taskbar-based file navigation system (ie, Windows Explorer, KDE, GNOME, etc.). It's much more space-efficient and can neatly tuck itself out of the say (don't get me started on Windows CE's "autohide" feature, because it goes crazy whenever I tap a little too close to its threshold)
I don't, however, think that Be is going to have a future on the desktop. BeOS is a niche that can easily be filled by Linux (with appropriate latency patches) or Mac OS X (which has all the posixy CLI goodness). Flame me if you like, I bought Be versions 4, 4.5, and 5, and I have BeBoxen running, but it's simply not going to achieve World Domination(TM) or even Neighborhood Domination(TM), simply because of the barriers to entry. Corporations work along the path of least resistance. So do most developers, I might add.
An interesting idea for handhelds would be Mac OS X. Because it is a microkernel, it can be trimmed to fit certain handheld devices. Moreover, Aqua is also a sexy interface, and -- if you pare away the Blue Box cruft -- its operating environment can be very lean. (objective C has, IMO, much less overhead). I wouldn't be surprised if Steve Jobs makes a nice, translucent colored plastic, Aqua-in-your-face, Newton II. I say, more power too him. Hell, OPENSTEP used to run on Motorola 25/33Mhz processors (and sparc, and PA-RISC, and intel..). I don't see why it wouldn't run on a Motorola Dragonball processor, much less a mobile G4 processor. A NeXT/Mac OS X-based PDA is a pretty damn good idea, actually. I would not be surprised if it came out within the next three years.
Now that I think of it...
On a side note, if anyone is interested in carving up some NeXT hardware to make an OpenStep PDA, gimme an e-mail
I have this tendency to ramble...
It seems a lot of people here aren't reading the article. Going over the specifications, I'm noticing a few things:
Bear in mind I'm not the most knowledgeable person in programming, so if I *am* wrong, don't just mod me down and insult me. Point out where, and I'll learn from the experience.
It seems from first glance that this language shares many superficial characteristics with Objective-C. No multiple inheritance, no operator overloading, etc.) It also seems that the author's rant on definition vs. declaration seems to be an attack on C++ prototyping in specific, but Objective-C seems to do the job quite well (with @interface versus @implementation blocks).
It also seems, from cursory surface examination, that D's "REAL typedefs" seem to resemble Objective-C's typedef'ing of the 'id' primitive -- which incidentally, does real dynamic binding on method return values. you return 'id' but based on whatever happens in the method, you can assign an int, long, whatever handle to it.
I don't like how all class copies are by reference. There are certain instances where a deep copy is required...
After all the ranting and raving about how operator overloading is worthless, the string (or should i say, "dynamic array") semantics seem to already have their operators overloaded, as given in the example code at http://www.digitalmars.com/d/arrays.html.
#import versus #include (where the included file has #ifndef __THIS_FILE_H...) was already addressed in Objective C, however the GNU compiler for Objective C is braindead and warns you unless you have -Wno-import (I think) set.
The inclusion of complex data types as primitives could easily be solved with a standard class library. The same applies for strings, etc. Yet D doesn't have an STL.
I'm all for new languages, and I wish the author success. Nor do I think the language lacks good points. I would, however, like the author to explain why he chose these courses of action, or differentiate more between D and something like Objective-C, or otherwise cluefy me.
/* don oh my god you're not funny */
I never claimed I was funny. I just wanted something that was less unfunny than the slew of obvious "this is a patch you can't refuse" jokes.
Because absolutely *everyone* here has either:
1) thought of the obvious Mafia jokes, or
2) bitched about how obvious the Mafia joke is and how it shouldn't be considered funny,
allow me, while ostensibly making a 'mob' joke, to bring a new and fresh topic of conversation to the table:
Who would win in a fight?
a) Don Corleone (young or old; your choice)
b) Don Juan
c) Don Quixote
d) Don Ho
e) Don Adams
f) Don Diego de la Vega
g) Don Knotts
h) Don Pablo
i) Donatello (artist)
j) Donatello (ninja turtle)
k) Don CowboyNeal