Hey, now that its out, has Sony released any info about the OS, (or any PS2 developers like to comment about it?) It seems to me that they did the right thing and stayed with their propriotory, lightweight OS, but what stuff have the put in to facilitate internet transfers, DVD playback, and web-browsing? Does this even have memory protection? While on the topic of OS, this is the kind of OS people dream about writing too. No bloated OS services to get in your way, direct access to every piece of hardware, and no other programs stealing your compute time, no worrying about swap file issues, tweeking the code perfectly to keep the pipes flowing, and no worrying about configuring perhiprals.
The reason that the Atari Jaguar was limited was not because it wasn't a PC. The N64 whooped any PC that was available at the time of its release (mainly P90 with Voodoos) It was limited because it was a weird hybrid 64 bit system except it had like 4 16 bit or 1 32 bit and 2 16 bit procs. It also had a weird controller and 0 developer support.
Its really sad that someone who has a bunch of goods points A) Has to hide behind an AC B) Hasn't been moderated up. This guy isn't a troll, he has quite a few good points, so why is it score zero? Slashdot seriously needs an overhaul of the moderation system. If I browse at 1, I miss these ACs which have insightful messages, and if I browse at 0, I get all the goat thingy links. You should be able to catagorize messages so you should be able to moderate obscene messages to flam-bait or off-topic, while keeping the other ACs to unmoderated or something.
Hey, does anyone know how the internals of this thing are arranged? If anything OpenGL is not a light API, so I doubt they used the standard openGL pipeline. If you think about it though, 3D on palmtops does stand a change, but OpenGL might not really be the best idea at this point. Back in the day, (386 days) you could acutally get a fairly non-complex, but usable 3D system on a 386-16. The dragon ball in the palm 3 is maybe slightly more powerful (20 MHz 68x00 I think) so it should be possible to get a decent API with OpenGL code interface to it. Also, does the dragonball have an fpu? Performance would die even more if it were using fpu emultation. (GL needs floats) Methinks a better target for this would be the CE machines as they are already coming in with 131MHz MIPS procs.
A few quibbles. A) DIrectPlay is a great idea. You write to a standard API, and the system uses whatever transport protocols are availabe. Maybe I don't like TCP/IP! Shouldn't I be able to use IPX if I want? I though you Linux people were all about flexibility and choice:) B) Alsa doesn't hold a candle to DirectSound and DirectMusic in terms of hardware acceleration and features. C) X is nowhere in the same league as DirectDraw. With DirectDraw I can shove the entire OS out of my way, get direct access to the frame-buffer, have direcaccess to hardware blitters, overlays, and other services, set up page flipping, etc. X pales in comparison, mainly because it isn't meant of the same jobs. Direct frambuffer access is nice, but thats just a small piece of DirectDraw. D) Direct3D ought to be replaced by OpenGL, true. (Actually, only after certain features have been put into OpenGL, as I remember Direct3D 7 has some features that aren't in GL) E)X gives you input, but so does the Win32 API! Thats not what DirectInput is about. It is about utter flexibility and speed. DirectInput bypasses the entire rest of the OS and talks directly to the driver. It can handle devices that haven't even been invented yet through the API. So, yes linux has some stuff, but it is a ghost of DirectX.
Face it, a GUI interface, done right, is inherently easier to learn than a text interface. When its done wrong (ie. Blender) it is worse than a text interface. (Don't mention Outlook in my presence btw.) Its also not so much how easy the thing is to learn, but a GUI gives the user a sense of control that you don't get with a CLI. Its a tacticle thing. Finally, a GUI is just better for most of the apps that users use. What to people mainly do with computers (home users) 1. Word Processing, spreadsheets, etc. (Office) 2. Internet 3. Gaming 4. Authoring, document development, photoshop, etc.
These are probably the top 4 uses of computers in the home. In all these apps, the GUI is infinetly more flexible than a CLI. People are naturaly visual creatures, and as long as they are GUIs will rule. Even for things that don't need a GUI (a lot of sysadmin stuff) a GUI is inherently less intimidating. Thats just the way people are. Once you've got experiance with something, then you can say that the CLI is so much more efficient at doing some things, but if you don't it will scare you away. GUIs are also friendlier. Its not so much an ease of use thing as a visually pleasing thing. Why do people build nice looking houses and nice looking cars? There are a bunch more efficient designs than the ones we have now, but people wouldn't want to use them. I am fairly good with the CLI, (bash) and find it usefull for doing many things. Still, I prefer to work in the GUI because it is just more astheticly pleasing. PS. If you want to script a GUI app take a look the BeOS. BeOS apps can use the messaging system to set up a scripting API. You have to use some lower level language though, like C, C++ or Python.
DirectX isn't actually a graphics API, it is a hardware access API. Theres no pixel, line or whatever functions, its just a library to control te graphics card (and sound and input, etc) directly. It is a good idea because its pretty stable, and only games usually use it. What I'm describing isn't really a microkernel approach, its a client-server approach. This could be implemented in linux too, except the app to server connection would be through function calls rather than messages.
Window managers are fine. Hell, windows has window managers. The problem is that the window manager defines too much functionality. You don't really care about programming to KDE vs. GNOME do you? You want them to look different, but everything under kwm and enlightenment is the same for both. (in a broad sense of course.) Thats a lot of reproduced funtionality that should really be a part of the OS, rather than part of the WM.
Are you kidding? GDI+ (the windows graphics interface) is a stinking piece of shit, and probably not much faster than X. Kernel graphics in general is not the best of ideas, but user spaces graphics can be just as fast. Take a look at beos. The graphics server is extremely responsive and the whole graphics system is really fast. Its entirly a function of design, though. The app has a direct connection through a very fast messaging system to the app server. (which handles graphics.) The app server implements most of the graphics driver; the kernel just implements a small part that deals with interupts and whatnot. Its a really beautiful desgin, because it incurs very little overhead, but is still very stable. I call an accelerated line draw, it sends a message to the app server, which uses the driver (in the form of a dynamic library) to acceleratadly draw the line. The app server, (or the user space driver for that matter) can't crash the system, so only bugs in the minscule kernel driver can cause problems.
Trickly down rarly results in a good OS. Consider Windows 2K. I was all ready to spring for it until they started advertising it right next to the RAM (I'm not kidding) at Office Depot. Something that has been designed for a particular purpose makes a much better OS. And yes, I think that Linux should concentrate on servers. I think it is a hopelessly messed up design and would never get accepted by the public. After all, UNIX was made for people who had tunnel vision and couldn't appreciate a GUI. Ease of use? Screw the grandmothers and uncles if they want to use a nice OS? Screw the Linux developers if they want to share their work with more than just the geek community. LISTEN TO YOURSELF, you sound like a troll. (If you weren't paying attention, I was being sarcastic.) People want to see Linux being accepted. It is a nice piece of work and if it wants to survive, then it has to be accepted. Nobody is going to take the CLI away from you, we just want to be able to use the damn OS!
Again, I've said this before, the problem with SDL is that it is directx style on the outside, but is missing the whole point of directX. DirectX is meant to be a library that directly abstracts the hardware, pushes the rest of the OS out of the way and provides accelerated everything. SDL is nice, but it is still software based. The only time it give the power of DirectX is under windows, and at that point you might as well use windows.
The main problem with DirectX through winlib is that you miss the point of DirectX. The library is nothing special, its the fact that it is a direct abstraction of hardware. Presumably, winlib directX just makes calls to the OSS soundsystem to emulate DirecSound or whatnot.
I happen to agree with the CEO of this company that Linux is not ready for the desktop. It is a great system, and for a UNIX the infrastructure underneath it is quite solid, at least much better than windows, and it has good developers behind it. The main problems, however, are. A) Linux does not have enough fit and finish, its not very polished. Say what you will about Windows, but it is very polished. The stuff underneath may suck, but the outside is nice and shiny. People like shiny things. Point about me: I'll generally use Redhat for examples because I feel that it strikes the best balance between ease of use and included features. Plus, most non techs think Redhat==Linux. (they don't even do the == thing to express equality, they say =) Redhat is generally pretty polished but there are quite a few problems. X still needs to be configured from Xconfigurator because the one in the installer is inept. Second, sound is left entirely to the user, one has to start up sndconfig and enter settings from there. Resolution changes all have to be done from the X config file, blah blah blah. These are all little things and don't have that much to do with the OS, but when a person first uses Linux, it makes a bad impression. B) Linux has a weird sense of configuration in that it doesn't really have a good driver model. Most users I know are comfortable with the concept of a driver. They don't understand what it does but they know that to install a device, they have to put in the driver disc. DevFS is great, except in UNIX it doesn't define a driver model, just a communications model. In BeOS, a user can just copy a driver into the directory and the device magically starts working. Linux should be that simple. (ie. no requiring kernel patches to install ANY device.) All config files are stored in/etc, which is okay for people who know UNIX, but face it, its a good idea implemented very badly. What there should be is a straight list of configuration files terminal, sound, network, startup, shutdown, discs, etc. Yet you have a horrible mess with multiple directories and not all config files having the same format. Its fine to keep that, but Linuxconf needs to be expanded to the point where editing a text file is never necessary. C) Software installation has to get a clue. People don't think of their installation as a set of files. They think of it as a directory. Thus there should be something analogous to a program files directory. RPM would ask you for the destination directory, and the app would install there. Tell me what you want about the flexibility of having/usr/usr/bin/usr/sbin/usr/local/bin/usr/local/sbin/opt and all that, but face it. Its a dumb idea implemented incorrectly. At least in windows program droppings (the files a program leaves on you system) is kept in scope to the \windows\system directory! In linux they install themselves all over the place. The ideal install structure would look like this. There is an apps folder,/apps. RPM installs everything into this folder, letting the user choose the name of the folder. Thus if the user wants to go into the folder for some reason, to make a shortcut or whatever, they know where it is. Adding and removing of programs would be done through RPM, so the frontend will be the same, and the back end will be more sane. D) Linux lacks hardware support. Not only in the case of OpenGL, which is getting better, but in sound and video and input, etc. Even when a driver works, it doesn't take full advantage of the hardware on the system. A sound blaster live! is awesome under windows, but not anything special under Linux because it doesn't support EAX. There is a reason for that. Manufacturers don't like hacks. Sure Aureal is porting A3D to linux, but in what form? Some sort of obscure dll wrapped hack. Linux and other UNIXes desperatly need multimedia APIs and driver models. Just as important this driver model has to be similar to directX. Not for any love of directX, mind you, but because thats what most hardware today accelerates and we want writing drivers to a UNIX media API to be easy as possible. WIndows users have gotten increadibly used to pampering. Windows is a much friendlier environment to use, even if the UI sucks. People understand it, and it has a lot of features to make life easier. Pervasive right click menus being one thing, context sensitive help, etc. No matter how good GNOME gets, thats not the whole of the system. The linux directory structure needs to be reworked and the concepts of administration need to be rethought. Now don't think you'll sacrifice flexibility in doing this. All this nice GUI config stuff can be done through text files, so if you like CLI, you can edit it directly. And somehow I doubt that you'll miss/usr/local/sbin (at least on the desktop.)
Although this is a troll, he has a point. A Windows machine with DirectX 7 and a GeForce card whoops any linux machine available at games if only for that fact that A) There is no comparable accelerated environment like DirectX on Linux. B) Linux doesn't have hardware support of a lot of things. C) Netscape really does suck! But its getting better. 3D is being done right, (ie direct access.) Opera is out (the web-browser equivilent of BeOS) and linux is getting more game friendly every day. Of course Linux will probably never have something comparable to directX, becase it would require a lot of people to work together on a project with disparate pieces, yet keep it slim. Linux projects can work together, but even in focused environments they have the nasty habit of reusing a lot of code (GNOME and imlib for example) which is great for normal programming, but is condusive to bloat, which is unacceptable for a thin layer like DirectX.
A) The graphics in todays games are leap years beyond 486 graphics. MYST may look cool, but it isn't real time and isn't interactive. Sure Quake3 still doesn't have as good graphics (in terms of photorealistich) as some of the 2D sprite games, but it is much more interactive. B) #D is the name of the game. 3D takes space, it take computing power. To draw even the most complex 2D sprite, all that is required is a blit of a 160K image, but to draw the same picture with 3D, it will take a few thousand polygons with a thousand verticies and a few matrix multiplies for each vertex plus color, shading and texture calculations. Not to mention that current games use something like 30 meg of textures, which shows there need of huge memory. Its not sloppy coding. The executable themselves aren't significantly larger, and the coding is probably even tighter. But when you have 3D scenes with a few million polygons per level and a total of a hundred megs of textures, memory gets hit. The Quake 3 executable is 830 kilobyes, but the.paq file, is 430 megabytes. Sure the executable loads a few DLLs, but the quake 3 installation is 464 meg, and 458 meg is tied up in levels and 3 meg in online services. That leave less than 3 meg of executable files.
Actually, programming a 3D engine with software support greatly reduces the things you can do with the hardware accelerated version. Graphics that are not superfical are hard to bring down. Many 3D rpgs also use textures and such for important information and losing those essentially changes the game. The problem is mainly that when making comprimises for fast software rendering, a lot of features have to be left out, even in accelerated modes. Plus most serious game players have PII and PIIIs so availibilty is franky not a problem. Even with the new MRM (basically tessalation) technologies coming out, it is more usefull on fast computers to deliver more consistant frame rate than to squeeze the game into a smaller computer.
It is interesting to me why all UNICIES are not compatible, given that all the relevant ones use X, have POSIX or SVR4 support, and all have many cross platform libraries. With all this inferstructure in place, it should be reletivly easy to standerdize the little inconsitancies between UNICIES to make them all completly source compatible with each other. Thus Solaris x86 should compile Linux x86 programs and Linux MIPS programs should compile on IRIX. This could come as an extension to POSIX, say 2.0? My point is that all UNICIES present a standard programming interface. The plumbing underneath is a greatly different, but from a program's point of view there is not a quantum leap in difference between Solaris and Linux and FreeBSD. Getting rid of the inconsistancies that remain would be a great help in getting UNIX accepted by more people. (Now wether or not the spread of UNIX is a good thing is up to you:)
Its insteresting how many people ignore the dangers of the simple cookie. I browse with cookies on by default, but in my autoexec.bat, I have a line that deltrees the enter temp, temp internet, cookies directory. Still, I get paranoid about people knowing where I go and who I am. I have a few questions however. Is it true that cookies can track your access to sites other than the one it is from. If so, what idiot put this feature in and what is his address. If you can't find it just search his name on Altavista. Second, isn't there possibly a better way to do this? Perhaps an electronic "profile" that would autmomatically get presented to non SSL sites, which one could concievibly load with junk information. However, enough of the rambling of an 80 year old grandmother living in Washington DC, Japan, making 0 dollars a year as CEO of a multinational corporation.:)
The way I see it, with all the games being ported to Linux and all, that Linux will become significantly less choatic than it is now. Linux reminds me of DOS/Win 3.1 in many ways, at least in terms of applications. The gaming environment back then was complex. I remember that Kings Quest 6 actually had you drop into the command line to install it! There were hacks and workarounds all over the place, proriotory APIs were being used, and there wasn't really a unified installation method. With mainstreamness (TM... My new word)comes unity, and I forsee Linux one day becoming better than Windows in this respect. (Whoa, put down the pitch-forks and hear me out!) Look at windows gaming today. The OS may be a piece of shit, but look at the infrastructure that MS has put in. There is a unified game API (DirectX) sure most good developers these days use OpenGL, but 3D is just a small (design, not code -wise) part of DirectX. Even an OpenGL developer would be a fool not to take advantage of everything from DirectInput and its ultra-flexible device handling, to DirectSound and its accelerated sound support, and DirectDraw and its accelerated everything support. I forsee Linux oneday having an API just like this, except instead of the hard-to-program closed API that is DirectX, it will be an open (source or not, I don't care) API that will be easily portable to different POSIX (and non POSIX) systems. I also see a standardized installation method. Variants of RPMS or DEBs except with much less complexity. And the LSB finally getting its act together so we will never have to harken back to the DOS days and hack the system just to get a game to work. The nifty thing about this is that there is no force required to develop this infrastructure. If it is built and built well, developers will come. There are about 0 serious developers that don't use autoplay or DirectX on windows. They could use something else, but why bother the user with it? And the cool thing will be that it won't be tied to one closed OS. (ie. It will be portable to BeOS:)
The heading (actually the title given to it by the university) is a little misleading. What we have here is not biological computing devices, for example like the ones that use a slugs brain cell to compute, but a new way to get at the cell. It will probably be more usefull to genetic engineering than anything else. (It says the cell opens and closes in a millisecond, which is an aweful long time.) That out of the way, I think this is really what is needed to take genetic engineering to the next level. By having a "door" as the article put it, into the cell, genetic engineering can take place much more easily. Although this current technology of integrating the cell into a chip will be great for experiments, this technoglogy can also be taken to the point where cells can be operated on directly, perhaps with some sort of probe. This does, however, raise again the ugly question of ethics and science. Anybody see the movie Gattica? (An awesome movie by the way) If something goes wrong with this technology (ie corperations get a hold of it before educational institutions) then Gattica might not seem so much like science fiction.
I never said otherwise. Manipulating XML is probably significantly easier than manipulating the raw text files that most UNICIES use. I wasn't really talking about MacOS and its database, I was mostly talking about text configuration files in most other OSes I've used. Also, I don't really see why an XML based registry is any easier to use than a binary registry. In addition Windows keeps numerous copies of the registry. It fairly rare for a normal uses to screw it, but when it happens, there is a big blowup.
Actually, believe it or not, a binary registry is much easier for the end-user to edit. (Not sysadmins with their scripts.) Firstly it has a much nicer implementation with the API. Windows has API calls to manipulate the registry. You can change your part without affecting other apps. Doing this in a text file is really hard because, well, there text files. One never edits the registry directly, it has to go through the system, either through Regedit or one of the APIs. This keeps the registry in a controlled state and faccilitates keeping all information in one place. If you've got the level of computer experiance needed to navigate your way through the mess of ASCII that is/etc, then you can edit the registry. In addition to providing a consistant access to the registry, it is still flexible enough that C programs can edit the registry, thus it is not hard to script. Also, the registry is not used in exactly the same way in UNIX and Windows. The registry is considered a persistant information storage for an app. UNIX could actually learn a lot from this approach. For example, instead of all the path statements and environmental variables, storing everything in the registry and providing and API for shell scripts to access it would be much better than what is in place now. Also, say I want to install an application that loads some image files from a certain directory. Instead of the hardcoded or assumed directories that are common in UNIX, you can store the value in the registry and retrieve it from there. True, it can also be done with a text file, but it is more clumsy that way. Say you install a large shared library, and a program wants to check the installed libraries version number. If it is in a registry, it would be easy for a library to post its version in a known place (yes I know that is an assumed or hardcoded link. But the registry could also be searched and searching a 4 meg registry is easier than searching for all directories on a system) and the app could access it from there. On the other hand, with a text file, the app would have to leave a file in/etc or something, which wastes space, inodes, and is risky if the user deletes it. In addition, it adds another layer of clutter to/etc. Of course I'm not saying that the/etc method is so bad, hell beos uses it. I'm just saying the registry method has some advantages. The only reason that you like windows any less is not the technical merits of the registry. Regedit on a window 95 machine is just as accessible as vi in Linux, you can easyily write C programs to edit them, and you can access regedit (or variations thereof) from telnet. The only reason you don't like it is because thats not what your used to.
Slashdot Mirror
No, this is more akin to DOS with libraries that directly access every piece of hardware and support acceleration. What exactly is wrong with that?
Hey, now that its out, has Sony released any info about the OS, (or any PS2 developers like to comment about it?) It seems to me that they did the right thing and stayed with their propriotory, lightweight OS, but what stuff have the put in to facilitate internet transfers, DVD playback, and web-browsing? Does this even have memory protection? While on the topic of OS, this is the kind of OS people dream about writing too. No bloated OS services to get in your way, direct access to every piece of hardware, and no other programs stealing your compute time, no worrying about swap file issues, tweeking the code perfectly to keep the pipes flowing, and no worrying about configuring perhiprals.
The reason that the Atari Jaguar was limited was not because it wasn't a PC. The N64 whooped any PC that was available at the time of its release (mainly P90 with Voodoos) It was limited because it was a weird hybrid 64 bit system except it had like 4 16 bit or 1 32 bit and 2 16 bit procs. It also had a weird controller and 0 developer support.
Its really sad that someone who has a bunch of goods points
A) Has to hide behind an AC
B) Hasn't been moderated up. This guy isn't a troll, he has quite a few good points, so why is it score zero? Slashdot seriously needs an overhaul of the moderation system. If I browse at 1, I miss these ACs which have insightful messages, and if I browse at 0, I get all the goat thingy links. You should be able to catagorize messages so you should be able to moderate obscene messages to flam-bait or off-topic, while keeping the other ACs to unmoderated or something.
Hey, does anyone know how the internals of this thing are arranged? If anything OpenGL is not a light API, so I doubt they used the standard openGL pipeline. If you think about it though, 3D on palmtops does stand a change, but OpenGL might not really be the best idea at this point. Back in the day, (386 days) you could acutally get a fairly non-complex, but usable 3D system on a 386-16. The dragon ball in the palm 3 is maybe slightly more powerful (20 MHz 68x00 I think) so it should be possible to get a decent API with OpenGL code interface to it. Also, does the dragonball have an fpu? Performance would die even more if it were using fpu emultation. (GL needs floats) Methinks a better target for this would be the CE machines as they are already coming in with 131MHz MIPS procs.
A few quibbles. :)
A) DIrectPlay is a great idea. You write to a standard API, and the system uses whatever transport protocols are availabe. Maybe I don't like TCP/IP! Shouldn't I be able to use IPX if I want? I though you Linux people were all about flexibility and choice
B) Alsa doesn't hold a candle to DirectSound and DirectMusic in terms of hardware acceleration and features.
C) X is nowhere in the same league as DirectDraw.
With DirectDraw I can shove the entire OS out of my way, get direct access to the frame-buffer, have direcaccess to hardware blitters, overlays, and other services, set up page flipping, etc. X pales in comparison, mainly because it isn't meant of the same jobs. Direct frambuffer access is nice, but thats just a small piece of DirectDraw.
D) Direct3D ought to be replaced by OpenGL, true. (Actually, only after certain features have been put into OpenGL, as I remember Direct3D 7 has some features that aren't in GL)
E)X gives you input, but so does the Win32 API! Thats not what DirectInput is about. It is about utter flexibility and speed. DirectInput bypasses the entire rest of the OS and talks directly to the driver. It can handle devices that haven't even been invented yet through the API.
So, yes linux has some stuff, but it is a ghost of DirectX.
Face it, a GUI interface, done right, is inherently easier to learn than a text interface. When its done wrong (ie. Blender) it is worse than a text interface. (Don't mention Outlook in my presence btw.) Its also not so much how easy the thing is to learn, but a GUI gives the user a sense of control that you don't get with a CLI. Its a tacticle thing. Finally, a GUI is just better for most of the apps that users use. What to people mainly do with computers (home users)
1. Word Processing, spreadsheets, etc. (Office)
2. Internet
3. Gaming
4. Authoring, document development, photoshop, etc.
These are probably the top 4 uses of computers in the home. In all these apps, the GUI is infinetly more flexible than a CLI. People are naturaly visual creatures, and as long as they are GUIs will rule. Even for things that don't need a GUI (a lot of sysadmin stuff) a GUI is inherently less intimidating. Thats just the way people are. Once you've got experiance with something, then you can say that the CLI is so much more efficient at doing some things, but if you don't it will scare you away. GUIs are also friendlier. Its not so much an ease of use thing as a visually pleasing thing. Why do people build nice looking houses and nice looking cars? There are a bunch more efficient designs than the ones we have now, but people wouldn't want to use them. I am fairly good with the CLI, (bash) and find it usefull for doing many things. Still, I prefer to work in the GUI because it is just more astheticly pleasing.
PS. If you want to script a GUI app take a look the BeOS. BeOS apps can use the messaging system to set up a scripting API. You have to use some lower level language though, like C, C++ or Python.
DirectX isn't actually a graphics API, it is a hardware access API. Theres no pixel, line or whatever functions, its just a library to control te graphics card (and sound and input, etc) directly. It is a good idea because its pretty stable, and only games usually use it. What I'm describing isn't really a microkernel approach, its a client-server approach. This could be implemented in linux too, except the app to server connection would be through function calls rather than messages.
What about if she wants to install a program? Do you really think she can handle RPM?
Window managers are fine. Hell, windows has window managers. The problem is that the window manager defines too much functionality. You don't really care about programming to KDE vs. GNOME do you? You want them to look different, but everything under kwm and enlightenment is the same for both. (in a broad sense of course.) Thats a lot of reproduced funtionality that should really be a part of the OS, rather than part of the WM.
Are you kidding? GDI+ (the windows graphics interface) is a stinking piece of shit, and probably not much faster than X. Kernel graphics in general is not the best of ideas, but user spaces graphics can be just as fast. Take a look at beos. The graphics server is extremely responsive and the whole graphics system is really fast. Its entirly a function of design, though. The app has a direct connection through a very fast messaging system to the app server. (which handles graphics.) The app server implements most of the graphics driver; the kernel just implements a small part that deals with interupts and whatnot. Its a really beautiful desgin, because it incurs very little overhead, but is still very stable. I call an accelerated line draw, it sends a message to the app server, which uses the driver (in the form of a dynamic library) to acceleratadly draw the line. The app server, (or the user space driver for that matter) can't crash the system, so only bugs in the minscule kernel driver can cause problems.
Trickly down rarly results in a good OS. Consider Windows 2K. I was all ready to spring for it until they started advertising it right next to the RAM (I'm not kidding) at Office Depot. Something that has been designed for a particular purpose makes a much better OS. And yes, I think that Linux should concentrate on servers. I think it is a hopelessly messed up design and would never get accepted by the public. After all, UNIX was made for people who had tunnel vision and couldn't appreciate a GUI. Ease of use? Screw the grandmothers and uncles if they want to use a nice OS? Screw the Linux developers if they want to share their work with more than just the geek community. LISTEN TO YOURSELF, you sound like a troll. (If you weren't paying attention, I was being sarcastic.) People want to see Linux being accepted. It is a nice piece of work and if it wants to survive, then it has to be accepted. Nobody is going to take the CLI away from you, we just want to be able to use the damn OS!
Again, I've said this before, the problem with SDL is that it is directx style on the outside, but is missing the whole point of directX. DirectX is meant to be a library that directly abstracts the hardware, pushes the rest of the OS out of the way and provides accelerated everything. SDL is nice, but it is still software based. The only time it give the power of DirectX is under windows, and at that point you might as well use windows.
The main problem with DirectX through winlib is that you miss the point of DirectX. The library is nothing special, its the fact that it is a direct abstraction of hardware. Presumably, winlib directX just makes calls to the OSS soundsystem to emulate DirecSound or whatnot.
I happen to agree with the CEO of this company that Linux is not ready for the desktop. It is a great system, and for a UNIX the infrastructure underneath it is quite solid, at least much better than windows, and it has good developers behind it. The main problems, however, are. /etc, which is okay for people who know UNIX, but face it, its a good idea implemented very badly. What there should be is a straight list of configuration files terminal, sound, network, startup, shutdown, discs, etc. Yet you have a horrible mess with multiple directories and not all config files having the same format. Its fine to keep that, but Linuxconf needs to be expanded to the point where editing a text file is never necessary. /usr /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin /opt and all that, but face it. Its a dumb idea implemented incorrectly. At least in windows program droppings (the files a program leaves on you system) is kept in scope to the \windows\system directory! In linux they install themselves all over the place. The ideal install structure would look like this. There is an apps folder, /apps. RPM installs everything into this folder, letting the user choose the name of the folder. Thus if the user wants to go into the folder for some reason, to make a shortcut or whatever, they know where it is. Adding and removing of programs would be done through RPM, so the frontend will be the same, and the back end will be more sane. /usr/local/sbin (at least on the desktop.)
A) Linux does not have enough fit and finish, its not very polished. Say what you will about Windows, but it is very polished. The stuff underneath may suck, but the outside is nice and shiny. People like shiny things. Point about me: I'll generally use Redhat for examples because I feel that it strikes the best balance between ease of use and included features. Plus, most non techs think Redhat==Linux. (they don't even do the == thing to express equality, they say =) Redhat is generally pretty polished but there are quite a few problems. X still needs to be configured from Xconfigurator because the one in the installer is inept. Second, sound is left entirely to the user, one has to start up sndconfig and enter settings from there. Resolution changes all have to be done from the X config file, blah blah blah. These are all little things and don't have that much to do with the OS, but when a person first uses Linux, it makes a bad impression.
B) Linux has a weird sense of configuration in that it doesn't really have a good driver model. Most users I know are comfortable with the concept of a driver. They don't understand what it does but they know that to install a device, they have to put in the driver disc. DevFS is great, except in UNIX it doesn't define a driver model, just a communications model. In BeOS, a user can just copy a driver into the directory and the device magically starts working. Linux should be that simple. (ie. no requiring kernel patches to install ANY device.) All config files are stored in
C) Software installation has to get a clue. People don't think of their installation as a set of files. They think of it as a directory. Thus there should be something analogous to a program files directory. RPM would ask you for the destination directory, and the app would install there. Tell me what you want about the flexibility of having
D) Linux lacks hardware support. Not only in the case of OpenGL, which is getting better, but in sound and video and input, etc. Even when a driver works, it doesn't take full advantage of the hardware on the system. A sound blaster live! is awesome under windows, but not anything special under Linux because it doesn't support EAX. There is a reason for that. Manufacturers don't like hacks. Sure Aureal is porting A3D to linux, but in what form? Some sort of obscure dll wrapped hack. Linux and other UNIXes desperatly need multimedia APIs and driver models. Just as important this driver model has to be similar to directX. Not for any love of directX, mind you, but because thats what most hardware today accelerates and we want writing drivers to a UNIX media API to be easy as possible.
WIndows users have gotten increadibly used to pampering. Windows is a much friendlier environment to use, even if the UI sucks. People understand it, and it has a lot of features to make life easier. Pervasive right click menus being one thing, context sensitive help, etc. No matter how good GNOME gets, thats not the whole of the system. The linux directory structure needs to be reworked and the concepts of administration need to be rethought. Now don't think you'll sacrifice flexibility in doing this. All this nice GUI config stuff can be done through text files, so if you like CLI, you can edit it directly. And somehow I doubt that you'll miss
Although this is a troll, he has a point. A Windows machine with DirectX 7 and a GeForce card whoops any linux machine available at games if only for that fact that
A) There is no comparable accelerated environment like DirectX on Linux.
B) Linux doesn't have hardware support of a lot of things.
C) Netscape really does suck!
But its getting better. 3D is being done right, (ie direct access.) Opera is out (the web-browser equivilent of BeOS) and linux is getting more game friendly every day. Of course Linux will probably never have something comparable to directX, becase it would require a lot of people to work together on a project with disparate pieces, yet keep it slim. Linux projects can work together, but even in focused environments they have the nasty habit of reusing a lot of code (GNOME and imlib for example) which is great for normal programming, but is condusive to bloat, which is unacceptable for a thin layer like DirectX.
A) The graphics in todays games are leap years beyond 486 graphics. MYST may look cool, but it isn't real time and isn't interactive. Sure Quake3 still doesn't have as good graphics (in terms of photorealistich) as some of the 2D sprite games, but it is much more interactive. .paq file, is 430 megabytes. Sure the executable loads a few DLLs, but the quake 3 installation is 464 meg, and 458 meg is tied up in levels and 3 meg in online services. That leave less than 3 meg of executable files.
B) #D is the name of the game. 3D takes space, it take computing power. To draw even the most complex 2D sprite, all that is required is a blit of a 160K image, but to draw the same picture with 3D, it will take a few thousand polygons with a thousand verticies and a few matrix multiplies for each vertex plus color, shading and texture calculations. Not to mention that current games use something like 30 meg of textures, which shows there need of huge memory. Its not sloppy coding. The executable themselves aren't significantly larger, and the coding is probably even tighter. But when you have 3D scenes with a few million polygons per level and a total of a hundred megs of textures, memory gets hit. The Quake 3 executable is 830 kilobyes, but the
Actually, programming a 3D engine with software support greatly reduces the things you can do with the hardware accelerated version. Graphics that are not superfical are hard to bring down. Many 3D rpgs also use textures and such for important information and losing those essentially changes the game. The problem is mainly that when making comprimises for fast software rendering, a lot of features have to be left out, even in accelerated modes. Plus most serious game players have PII and PIIIs so availibilty is franky not a problem. Even with the new MRM (basically tessalation) technologies coming out, it is more usefull on fast computers to deliver more consistant frame rate than to squeeze the game into a smaller computer.
It is interesting to me why all UNICIES are not compatible, given that all the relevant ones use X, have POSIX or SVR4 support, and all have many cross platform libraries. With all this inferstructure in place, it should be reletivly easy to standerdize the little inconsitancies between UNICIES to make them all completly source compatible with each other. Thus Solaris x86 should compile Linux x86 programs and Linux MIPS programs should compile on IRIX. This could come as an extension to POSIX, say 2.0? My point is that all UNICIES present a standard programming interface. The plumbing underneath is a greatly different, but from a program's point of view there is not a quantum leap in difference between Solaris and Linux and FreeBSD. Getting rid of the inconsistancies that remain would be a great help in getting UNIX accepted by more people. (Now wether or not the spread of UNIX is a good thing is up to you :)
Its insteresting how many people ignore the dangers of the simple cookie. I browse with cookies on by default, but in my autoexec.bat, I have a line that deltrees the enter temp, temp internet, cookies directory. Still, I get paranoid about people knowing where I go and who I am. I have a few questions however. Is it true that cookies can track your access to sites other than the one it is from. If so, what idiot put this feature in and what is his address. If you can't find it just search his name on Altavista. Second, isn't there possibly a better way to do this? Perhaps an electronic "profile" that would autmomatically get presented to non SSL sites, which one could concievibly load with junk information. However, enough of the rambling of an 80 year old grandmother living in Washington DC, Japan, making 0 dollars a year as CEO of a multinational corporation. :)
The way I see it, with all the games being ported to Linux and all, that Linux will become significantly less choatic than it is now. Linux reminds me of DOS/Win 3.1 in many ways, at least in terms of applications. The gaming environment back then was complex. I remember that Kings Quest 6 actually had you drop into the command line to install it! There were hacks and workarounds all over the place, proriotory APIs were being used, and there wasn't really a unified installation method. With :)
mainstreamness (TM... My new word)comes unity, and I forsee Linux one day becoming better than Windows in this respect. (Whoa, put down the pitch-forks and hear me out!) Look at windows gaming today. The OS may be a piece of shit, but look at the infrastructure that MS has put in. There is a unified game API (DirectX) sure most good developers these days use OpenGL, but 3D is just a small (design, not code -wise) part of DirectX. Even an OpenGL developer would be a fool not to take advantage of everything from DirectInput and its ultra-flexible device handling, to DirectSound and its accelerated sound support, and DirectDraw and its accelerated everything support. I forsee Linux oneday having an API just like this, except instead of the hard-to-program closed API that is DirectX, it will be an open (source or not, I don't care) API that will be easily portable to different POSIX (and non POSIX) systems. I also see a standardized installation method. Variants of RPMS or DEBs except with much less complexity. And the LSB finally getting its act together so we will never have to harken back to the DOS days and hack the system just to get a game to work. The nifty thing about this is that there is no force required to develop this infrastructure. If it is built and built well, developers will come. There are about 0 serious developers that don't use autoplay or DirectX on windows. They could use something else, but why bother the user with it? And the cool thing will be that it won't be tied to one closed OS. (ie. It will be portable to BeOS
The heading (actually the title given to it by the university) is a little misleading. What we have here is not biological computing devices, for example like the ones that use a slugs brain cell to compute, but a new way to get at the cell. It will probably be more usefull to genetic engineering than anything else. (It says the cell opens and closes in a millisecond, which is an aweful long time.) That out of the way, I think this is really what is needed to take genetic engineering to the next level. By having a "door" as the article put it, into the cell, genetic engineering can take place much more easily. Although this current technology of integrating the cell into a chip will be great for experiments, this technoglogy can also be taken to the point where cells can be operated on directly, perhaps with some sort of probe. This does, however, raise again the ugly question of ethics and science. Anybody see the movie Gattica? (An awesome movie by the way) If something goes wrong with this technology (ie corperations get a hold of it before educational institutions) then Gattica might not seem so much like science fiction.
I never said otherwise. Manipulating XML is probably significantly easier than manipulating the raw text files that most UNICIES use. I wasn't really talking about MacOS and its database, I was mostly talking about text configuration files in most other OSes I've used. Also, I don't really see why an XML based registry is any easier to use than a binary registry. In addition Windows keeps numerous copies of the registry. It fairly rare for a normal uses to screw it, but when it happens, there is a big blowup.
Actually, believe it or not, a binary registry is much easier for the end-user to edit. (Not sysadmins with their scripts.) Firstly it has a much nicer implementation with the API. Windows has API calls to manipulate the registry. You can change your part without affecting other apps. Doing this in a text file is really hard because, well, there text files. One never edits the registry directly, it has to go through the system, either through Regedit or one of the APIs. This keeps the registry in a controlled state and faccilitates keeping all information in one place. If you've got the level of computer experiance needed to navigate your way through the mess of ASCII that is /etc, then you can edit the registry. In addition to providing a consistant access to the registry, it is still flexible enough that C programs can edit the registry, thus it is not hard to script. Also, the registry is not used in exactly the same way in UNIX and Windows. The registry is considered a persistant information storage for an app. UNIX could actually learn a lot from this approach. For example, instead of all the path statements and environmental variables, storing everything in the registry and providing and API for shell scripts to access it would be much better than what is in place now. Also, say I want to install an application that loads some image files from a certain directory. Instead of the hardcoded or assumed directories that are common in UNIX, you can store the value in the registry and retrieve it from there. True, it can also be done with a text file, but it is more clumsy that way. Say you install a large shared library, and a program wants to check the installed libraries version number. If it is in a registry, it would be easy for a library to post its version in a known place (yes I know that is an assumed or hardcoded link. But the registry could also be searched and searching a 4 meg registry is easier than searching for all directories on a system) and the app could access it from there. On the other hand, with a text file, the app would have to leave a file in /etc or something, which wastes space, inodes, and is risky if the user deletes it. In addition, it adds another layer of clutter to /etc. Of course I'm not saying that the /etc method is so bad, hell beos uses it. I'm just saying the registry method has some advantages. The only reason that you like windows any less is not the technical merits of the registry. Regedit on a window 95 machine is just as accessible as vi in Linux, you can easyily write C programs to edit them, and you can access regedit (or variations thereof) from telnet. The only reason you don't like it is because thats not what your used to.
Dumbass snob. The "Real ISP" users should be saying thank-you to the "dumbass" ISP for letting them use THEIR network.