I think we're barking up the wrong tree using light-emitting technology for displays. I think that we would be far better off having a very high-res, paper-white display that was 100% reflective. Indeed others have called this "digital paper" and it has become a holy grail of display technologies. However the technology to do this is just about here now. I'd much rather see that kind of display. Give me a reflective, 600 dpi display and then I'll read books on a computer. Light-emitting displays are much harder on my eyes than a magazine or newspaper.
Because there is no obstacle. All KDE libs* are LGPL, you have no obligation to GPL a KDE application.
How is this possible? The QT libraries are GPL. The KDE libraries link against them. Therefore if they aren't GPL'd also (they are indeed LGPL), they are in violation of the GPL. Is this not so?
Even if a developer has a license to develop non-GPL programs with QT (which do integrate with the KDE desktop pretty well), I don't think it's possible to develop non-GPL KDE apps because the KDE libs are GPL'd. Although I prefer that everyone embrace the GPL, that isn't going to happen and I wonder if that issue plus the $2000 source license fee isn't a huge obstacle to corporate KDE deployment. How did theKompany get around that obstacle and make commercial KDE apps?
That's all nice and dandy. But how about a simple thing like the windows not flickering when getting moved/resized.
It's all part of the deal. Read the docs at www.freedesktop.org and you'll see how the composite extensions now only can give you special effects, but allow for smoother redraws, due to the buffering that's now possible. A lot of flicker in the past has resulted from redraws. The XDamage extension can now drastically minimize this, as I understand it, but double-buffering using a composite manager will dramatically improve things as redraws are practically eliminated for things like expose events.
It seems the X developers *still* do not get it, there is nothing here that is going to address any of the big issues with XFree, just more of the same.
Sigh. And what issues are these? Have you talked to any of the X11 gurus lately, such as Keith Packard. I assure you they very much do "get it" and are doing wonderful things to make an already amazing framework even better. X11 is an amazing piece of work, one that is still working well today, almost 16 years after it was introduced. With the new extensions being worked on to allow compositing and true alpha channel blending, and because of the brilliant way in which is being done, the capacities of X11 can rival or even surpass Apple's Quartz system. No more nasty hacks are needed to simulate transparency. Everything from true live matrix transforms (imagine live windows morphing in real-time, something that even OS X fakes) to 3-d capabilities (the composite manager can map the live windows onto surfaces of polygons and use opengl to render them) without fundementally breaking the X11 protocol. In other words, remote log into an old SGI box and your apps will still run and have these effects.
Dispite all the work that's being done to make X11 better, it's number one killer feature has always been network transparency. Fortunately many of the security concerns of this are being addressed; X11 will probably soon no longer default to tcp/ip connections, but rather use unix-style sockets only and have ssh connect them. (Very few people have a real good reason to not tunnel X11 through ssh anyway).
So things are looking really good for the Linux desktop and X11. I'm excited for the next year and hope to be able to contribute in some small way. We have 2 years to really develop some great features before longhorn comes out. Hopefully with things like the composite extension, we can have more capabilities sooner.
Although DVDs are higher quality video than VHS or any other current analog format, the video quality on DVDs really is actually quite poor. Although not as bad as DivX (or Mpeg/4), during high motion sequences, things pixelate (from compression) and fine detail in images has a lot of jpeg artifacts (around the edges of titles is particularly noticable). Fortunately, HDTV isn't really that high of resolution anyway, so most probably won't notice. The irony is that because we have crappy (blurry) TVs and projectors, things actually look sharper to the eye, which is why most people don't notice these things. But put it on a sharp hires screen, like a computer monitor, and things just look bad. DVDs definitely represent an improvement in image quality over VHS, but I've only been disappointed in them.
A sad note here is that the one compression algorithm that could both satisfy the high compression ration need of video and look good is fractal compression, which is completely locked down by one company that owns all the patents and that's doing practically nothing with it. Such a waste, it's sad.
We recently purchased 2 apple xserve arrays totalling 4.5 raw terabytes of data for a price that none of the storage venders could match. We have the arrays set up to do two different luns, each radi5/1 with a hot spair (Raid/5 and then mirrored). All using 180 gb ide disks. We currenty use Panther Server on XServe boxes to serve nfs, samba and afs, but the cool thing about these arrays is that they are standard fibre channel. You can hook them to any box and any OS that can handle fibre channel. The hardware arrays simply set themselves up as scsi luns. The admin software is java based and runs perfectly under linux. I think anyone looking into a storage solution for windows or linux should consider the apple arrays even if they have no intention of ever using Mac OS X or mac hardware.
Yup, the problem is squarely with Delphi. It arrived too late on Linux, when there were already free IDEs of comparable quality and in much wider distribution.
Precisely. Development tools have largely been comodotized over the years and the amount of money to be made, even in the windows market, is drying up for companies such as Borland. On the unix side we already have a lot of freely available and free compilers for every language out there. Even FreePascal, which is already language compatible with delphi; all it needs is a replacement for the VCL library. A host of very good IDEs are also available now, including Kdevelop, Anjuta, and even Eclispe. Many of these are starting to have RAD features. Even on windows, the development environment is pretty much exclusively VisualStudio.NET. Even though it isn't free, it's ubiquitous amongst developers such that any other tool is going to have a hard sell, unless it is free.
Borland's days are numbered, on all platforms. The development tools market has been vastly inflated over the years (just like software development in general), and players are now starting to feel it. Like the OS, the compiler is starting to just be expected to be a part of the system. I'm not sure this is a bad thing, either. In a way it's a little like the invention of the printing press destroyed the monopoly that some held on the reading of books, since they were rare and hard to copy. For years there was a certain barrier to entry imposed on developers by companies like borland. If you wanted to develop software, you had to pay them for the tools. Now the tools are free in many cases, and as with all tools, tools can be used to make better tools, which many of us give away for free.
The easiest way to delete New.Net is to do the following: 1. remove it using "Add/remove" programs 2. if still not working, remove the WinSock and WinSock2 registry keys from CurrentControlSet 3. Go to network settings on win98 or on 2000/XP, just go into the properties of your network connection and if possible, remove tcp/ip. On XP this is impossible, so ignore this step 4. Add new service. If you're not on XP, just reinstall tcp/ip. On XP, select "have disk" and point it at C:\windows\inf. Then select tcp/ip and install it 5. clean up any newdotnet files lying around. 6. Join a class-action lawsuit against the company that makes this piece of crapware.
Be aware that these steps can cause problems with programs like cyber-sitter or firewalling programs that modify the networking stack. Do this at your own risk.
This is very prolific. I've cleaned it on on laptop twice! I have a supsicion the user is downloading crap all the time, but I do wonder in what form it come in.
My recommendation to keep RedHat 9 going past it's end of life is to simply get the GPL'd rpms for RHEL for the vital packages and install them. Either that or patch rh9 using rh10 (or whatever) sources.
They're having problems with some of their machines, including the one which distributes mod points, running slow.
This begs the question, what would happen if several thousand users decided to "go on strike" as it were and simply withhold moderation points. Seems to me that if enough users did this, we would see a similar moderation point shortage.
On the other hand we have nearly 800,000 slashdot accounts theses days, and the possibility of any of them agreeing to anything to accomplish this would be about zero.
Processors always run at full speed. It's just they're executing NOPs when they're "idle
Most processors these days actually execute a "halt" instruction in the idle loop, which essentially sleeps the processor until the next interrupt from the scheduler. So no, they don't run at full speed always.
I always wonder why Windows users need an installer. Somehow Mac users have got along fine with it for years. Just unpack the dang thing to program files, drag a shortcut onto your desktop. How hard can it be? This is the number one feature of Firebird, in my opinion (ok, besides the tabs, the beautiful interface, etc). I unpack Firebird onto a usb keydrive and then I can run my favorite browser on any windows machine without having to install anything.
As for plugins, even though the plugin installers such as java and flash don't recognize Firebird, Firebird always manages to find them. Same for quicktime.
Miguel's position has always been that it is the benefits of the C# language and runtime that he is looking to bring to Linux, not just straight compatibility. Even if MS changed their target and broke their class library APIs tomorrow it wouldn't matter, because that's not what it's about. The real advantage to Linux application development can be seen in the GTK# project, which has no equivalent in the MS version of the CLR. GTK# and C# allow us to rapidly prototype and develop GUI's that we can use in typical Unix fashion to build tools out of smaller components. Personally I don't care if my C# apps run on windows on.NET. They will run wherever Mono runs. I believe that with GTK# and other gui libraries on Linux, C# fills the RAD niche far better than Java.
Anyway, all of these arguments have already been made against Mono and Miguel has effectively answered them all. Read the Mono FAQs. I don't believe that the Mono project will help Microsoft embrace and extend the web. Besides I don't see how a language runtime and a language itself will somehow magically subvert the net. Mono will support the Microsoft protocols (if they can be called that) that are openly documented.
We are at a critical juncture in our battle with Microsoft (to paraphrase Star Wars). The empire has made a critical error (in timing) and the time for our attack has come. With Longhorn delayed until 2006, we have an unprecedented (yes I like that word) opportunity to really polish and advance Linux, and I think C# and the Mono CLR can greately enhance Linux' position on the desktop, and on the server, as an alternative to server-side Java.
I'm amazed at how far Linux has come since the days in 1998 when I was first introduced to it, and I see in the next 2 years Linux going as far again as it did in the last 5 years. (SCO be damned.)
I've said this everytime an article on yet another embedded framebuffer attempt is posted. While embedded solutions like MiniGUI and QT/Embedded seem like great ideas, they both suffer from the same problems. First off, all though I love the GPL and wish that everything were GPL'd, in the case of the windowing system/widget set, the GPL is not appropriate. LGPL is more appropriate. Because the widget set is part of the windowing envirnoment, you can't write code under any other license for the environment, because it's GPL'd. This right away will limit MiniGUI's viability, because for most embedded developes, it will not be an option. QT/Embedded, of course can be purchased to avoid this issue.
Secondly, like all embedded framebuffer attempts, this one yet again reinvents the wheel, defining a windowing system, event-handling, input-handling and so forth. And of course only programs using that exact API can run on this environment. This is a significant restriction that I find rather suffocating when I am using OPIE on my Zaurus.
For many devices, including handhelds, the best solution is still venerable X11. Keith Packard's KDrive server is completely self-contained (font support, XRender support) and weighs in at just 700 kb. Run a lightweight environment such as matchbox on top of that (wonderful window manager designed for handhelds) with a nice light widget set, and you have all the same features as this MiniGUI without the restrictions it imposes. See what the gpe people have done with this. It's impressive. In such an X11-based environment, MiniGUI could be viable because it wouldn't exclude any other toolkits or APIs from being used.
The final problem I see with MiniGUI is that code appears more complicated and MS-ish than QT or GTK. Clearly the developers come from a win32 background, as MiniGUI code is full of win32-isms, which I find harder to program and less elegant than the Signal/Slot mechanisms of QT and GTK.
Clearly, with or without X11 you need to change the widget look and behavior from that on a desktop. The idea of "windows" becomes less important as full-screen is the only desirable mode. Modifying the input mechanism is also important. Things that we take for granted on desktops such as right-clicking don't translate well to a handheld. QT/E and gpe solve this by having the user hold his stylus on the widget for a couple of seconds to emulate the right-mouse-button-click.
There is no perfect system, and MiniGUI appears to be yet another attempt and I'm sure has a valid niche to fill. I wish them well.
The earth, everyone knows, was commissioned by the white mice as a great computer to compute the question to Life, the Universe, and Everything, for which the answer is 42, and was built by the custom luxury planet builders of Magrithea, although it was destroyed just before it had found the question.
"'These creatures you call mice, you see, they are not quite as they appear. They are merely the protrusion into our dimension of vastly hyperintelligent pandimensional beings. The whole business with the chesse and the squeaking is just a front.'
The old man pause, and with a sympathetic frown continued. 'They've been experimenting on you, I'm afraid.'
Arthur thought about this for a seond, and then his face cleared.
'Ah no,' he said, 'I see the source of the misunderstanding now. No, look, you see what happened was that we used to do experiements on them.... So what would happen was that the mice would run round mazes and things so that the whole nature of the learning process could be examined. From our observations of their behavior we were able to learn all sorts of things about our own...'
Arthur's voice trailed off.
'Such subtlety...' said Slartibartfast, 'one has to admire it.'"
Having support in the kernel for devices and auto-detection and setup of those drivers are two different issues. Hardware detection and configuration (especially of removable devices) has been and should remain in user-space projects, such as hotplug, kudzu, and the Knoppix hardware detection routines. Most hardware devices need userspace support, anyway (such as setting up dev entries, modifying fstab etc).
One just need pop in a knoppix CD to see just how plug-and-play Linux really is. Most of the time it just works. Better than windows at times.
Building a detection routine into the kernel build process would be fantastic, though. How about taking this one step further. Have hotplug or some other monitoring program detect the new hardware, and if there's no driver already compiled, builds a module on the fly and loads it. A bit slow, but now slower than the windows wizard method for installing hardware. If you added the capability to have signed driver source code (and had a few locations of trusted code repositories, the program could go out and get the latest module code and try that.
This is not what the original poster was asking for. The kernel monte actually just does an effective reboot without going throug the bios. As I understand it, the kernel monte cannot tranfer running processes from one kernel to another. Last time I used it, the monte killed all my processes, and reloaded init (basically rebooting).
What the poster wants (and what I want) is the ability to load a new kernel, transfer the existing kernel tables (process, resource, driver status, etc) over to the new kernel and have things continue without interruption.
Michael
Re:SVG is not the future
on
GIMP goes SVG
·
· Score: 5, Interesting
IE doesn't support flash either, and it's wide-spread. All you need is to embedd a link to the SVG active-X control and users will pick it up on the fly. No big deal. Average Joe's don't even know flash isn't supported natively. They still use it.
Don't look for any new features in IE for the next several years. By integrating it tightly into the OS and killing it as a standalone product, Microsoft has effectively eliminated all potential innovation in the browser area, since browser releases now equals OS releases. IE 7 won't be out until Longhorn (at least a year away), and even then it won't be widely used as most people will never migrate off XP for the life of their machines.
This is an unprecedented opportunity for Mozilla to win the browser war. Being a standalone installable app (that can run on win98 and up), Mozilla can add new features and support new standards. Just spread the word. Tell your friends. Talk to your favorite web developers.
Since xen is really a machine monitor, not an operating system, you won't be able to simple cut and paste between them. However, there are a number of utilities out there that can link clipboards (windows and linux) over a network connection. One example is MpCb, at http://www.idata.sk/~robo/mpcb/.
With software like MpCb, and if Xen supports virtual terminals, you could easily switch back and forth between, say XP and Linux. I know our CS computer labs would love that.
Depending on how flexible Xen is, one could run two video cards, keyboards, and monitors, and have completely separate terminals and OS's running on e one machine. This is seriously cool.
I've only had experience with the H-ITT device (http://www.h-itt.com). It's IR and has lots of problems when everyone uses it at once. Based on my experience with this, I think some kind of rf-thing is better. Perhaps some like of 802.11 or something that can handle overlapping requests.
For any that are interested, I've reverse-engineered the serial line protocol for H-ITT, which would allow one to write their own clients for the hardware. H-ITT only gives out the software for Windows, and dispite the academic demand refuse to develop for Macintosh, so we are working on a Mac app for our faculty.
Re:Does this ver. solve the WinXP security "featur
on
Samba 3.0.0 Released
·
· Score: 2, Informative
This is a well-documented problem with XP and 2000 when service pack 4 is installed. Besides setting the registry entry "RequireSignOrSeal" to "0," you must run the "mmc" program, add a "Group Policy" Snap-in, then in there find and option that says something about ignore permissions on roaming profile. Set that to "enabled." I'm not yet at work, but when I get there, I'll get the exact key name and post it here. A quick search of google reveals it's not terribly obvious, although I found this before.
The interesting thing about the 49G (not the new 49G+) is that is based on the same Saturn processor that the 48G series was. 4mHz RISC with special 64-bit registers (to hold floating point numbers) and a 4-bit memory bus (but a 20-something-bit address space I think). However the 49G run something like 10 times faster than the 48G. This is due entirely to optimizing the operating system and rom routines. Amazing what optimization at the assembler level, when done properly, can do.
Will this mean that security updates will still be available for RedHat 7.3 after it is End of Life'd at the end of this year? If not then I will still be switching to Debian when that happens.
Anyone have any insight on that issue, which is the biggest one by far at present for me regarding RedHat?
I expect the same issues to remain with redhat fedora. However under redhat fedora linux you can just apt-get dist-upgrade every year or so. For a workstation, this the best way, anyway. For a server, RedHat's really pushing for their slower-moving enterprise product which will have much longer lifespan.
What I'm doing with my old venerable redhat 6.2 server is taking relavent rh 9 security patches (sendmail an openssh to name two) and recompiling them for rh 6.2 In most cases, it's just a matter of tweaking the the spec file a bit (rh's openssh rpm still has build options for 6.2 that I can turn on) and spitting out some patched rpms.
Slashdot Mirror
I think we're barking up the wrong tree using light-emitting technology for displays. I think that we would be far better off having a very high-res, paper-white display that was 100% reflective. Indeed others have called this "digital paper" and it has become a holy grail of display technologies. However the technology to do this is just about here now. I'd much rather see that kind of display. Give me a reflective, 600 dpi display and then I'll read books on a computer. Light-emitting displays are much harder on my eyes than a magazine or newspaper.
How is this possible? The QT libraries are GPL. The KDE libraries link against them. Therefore if they aren't GPL'd also (they are indeed LGPL), they are in violation of the GPL. Is this not so?
Even if a developer has a license to develop non-GPL programs with QT (which do integrate with the KDE desktop pretty well), I don't think it's possible to develop non-GPL KDE apps because the KDE libs are GPL'd. Although I prefer that everyone embrace the GPL, that isn't going to happen and I wonder if that issue plus the $2000 source license fee isn't a huge obstacle to corporate KDE deployment. How did theKompany get around that obstacle and make commercial KDE apps?
It's all part of the deal. Read the docs at www.freedesktop.org and you'll see how the composite extensions now only can give you special effects, but allow for smoother redraws, due to the buffering that's now possible. A lot of flicker in the past has resulted from redraws. The XDamage extension can now drastically minimize this, as I understand it, but double-buffering using a composite manager will dramatically improve things as redraws are practically eliminated for things like expose events.
Sigh. And what issues are these? Have you talked to any of the X11 gurus lately, such as Keith Packard. I assure you they very much do "get it" and are doing wonderful things to make an already amazing framework even better. X11 is an amazing piece of work, one that is still working well today, almost 16 years after it was introduced. With the new extensions being worked on to allow compositing and true alpha channel blending, and because of the brilliant way in which is being done, the capacities of X11 can rival or even surpass Apple's Quartz system. No more nasty hacks are needed to simulate transparency. Everything from true live matrix transforms (imagine live windows morphing in real-time, something that even OS X fakes) to 3-d capabilities (the composite manager can map the live windows onto surfaces of polygons and use opengl to render them) without fundementally breaking the X11 protocol. In other words, remote log into an old SGI box and your apps will still run and have these effects.
Dispite all the work that's being done to make X11 better, it's number one killer feature has always been network transparency. Fortunately many of the security concerns of this are being addressed; X11 will probably soon no longer default to tcp/ip connections, but rather use unix-style sockets only and have ssh connect them. (Very few people have a real good reason to not tunnel X11 through ssh anyway).
So things are looking really good for the Linux desktop and X11. I'm excited for the next year and hope to be able to contribute in some small way. We have 2 years to really develop some great features before longhorn comes out. Hopefully with things like the composite extension, we can have more capabilities sooner.
Although DVDs are higher quality video than VHS or any other current analog format, the video quality on DVDs really is actually quite poor. Although not as bad as DivX (or Mpeg/4), during high motion sequences, things pixelate (from compression) and fine detail in images has a lot of jpeg artifacts (around the edges of titles is particularly noticable). Fortunately, HDTV isn't really that high of resolution anyway, so most probably won't notice. The irony is that because we have crappy (blurry) TVs and projectors, things actually look sharper to the eye, which is why most people don't notice these things. But put it on a sharp hires screen, like a computer monitor, and things just look bad. DVDs definitely represent an improvement in image quality over VHS, but I've only been disappointed in them.
A sad note here is that the one compression algorithm that could both satisfy the high compression ration need of video and look good is fractal compression, which is completely locked down by one company that owns all the patents and that's doing practically nothing with it. Such a waste, it's sad.
We recently purchased 2 apple xserve arrays totalling 4.5 raw terabytes of data for a price that none of the storage venders could match. We have the arrays set up to do two different luns, each radi5/1 with a hot spair (Raid/5 and then mirrored). All using 180 gb ide disks. We currenty use Panther Server on XServe boxes to serve nfs, samba and afs, but the cool thing about these arrays is that they are standard fibre channel. You can hook them to any box and any OS that can handle fibre channel. The hardware arrays simply set themselves up as scsi luns. The admin software is java based and runs perfectly under linux. I think anyone looking into a storage solution for windows or linux should consider the apple arrays even if they have no intention of ever using Mac OS X or mac hardware.
Precisely. Development tools have largely been comodotized over the years and the amount of money to be made, even in the windows market, is drying up for companies such as Borland. On the unix side we already have a lot of freely available and free compilers for every language out there. Even FreePascal, which is already language compatible with delphi; all it needs is a replacement for the VCL library. A host of very good IDEs are also available now, including Kdevelop, Anjuta, and even Eclispe. Many of these are starting to have RAD features. Even on windows, the development environment is pretty much exclusively VisualStudio.NET. Even though it isn't free, it's ubiquitous amongst developers such that any other tool is going to have a hard sell, unless it is free.
Borland's days are numbered, on all platforms. The development tools market has been vastly inflated over the years (just like software development in general), and players are now starting to feel it. Like the OS, the compiler is starting to just be expected to be a part of the system. I'm not sure this is a bad thing, either. In a way it's a little like the invention of the printing press destroyed the monopoly that some held on the reading of books, since they were rare and hard to copy. For years there was a certain barrier to entry imposed on developers by companies like borland. If you wanted to develop software, you had to pay them for the tools. Now the tools are free in many cases, and as with all tools, tools can be used to make better tools, which many of us give away for free.
How have these solar flares impacted the ISS? Have they been exposed to increased amounts of radiation?
The easiest way to delete New.Net is to do the following:
1. remove it using "Add/remove" programs
2. if still not working, remove the WinSock and WinSock2 registry keys from CurrentControlSet
3. Go to network settings on win98 or on 2000/XP, just go into the properties of your network connection and if possible, remove tcp/ip. On XP this is impossible, so ignore this step
4. Add new service. If you're not on XP, just reinstall tcp/ip. On XP, select "have disk" and point it at C:\windows\inf. Then select tcp/ip and install it
5. clean up any newdotnet files lying around.
6. Join a class-action lawsuit against the company that makes this piece of crapware.
Be aware that these steps can cause problems with programs like cyber-sitter or firewalling programs that modify the networking stack. Do this at your own risk.
This is very prolific. I've cleaned it on on laptop twice! I have a supsicion the user is downloading crap all the time, but I do wonder in what form it come in.
Michael
My recommendation to keep RedHat 9 going past it's end of life is to simply get the GPL'd rpms for RHEL for the vital packages and install them. Either that or patch rh9 using rh10 (or whatever) sources.
This begs the question, what would happen if several thousand users decided to "go on strike" as it were and simply withhold moderation points. Seems to me that if enough users did this, we would see a similar moderation point shortage.
On the other hand we have nearly 800,000 slashdot accounts theses days, and the possibility of any of them agreeing to anything to accomplish this would be about zero.
Most processors these days actually execute a "halt" instruction in the idle loop, which essentially sleeps the processor until the next interrupt from the scheduler. So no, they don't run at full speed always.
I always wonder why Windows users need an installer. Somehow Mac users have got along fine with it for years. Just unpack the dang thing to program files, drag a shortcut onto your desktop. How hard can it be? This is the number one feature of Firebird, in my opinion (ok, besides the tabs, the beautiful interface, etc). I unpack Firebird onto a usb keydrive and then I can run my favorite browser on any windows machine without having to install anything.
As for plugins, even though the plugin installers such as java and flash don't recognize Firebird, Firebird always manages to find them. Same for quicktime.
Miguel's position has always been that it is the benefits of the C# language and runtime that he is looking to bring to Linux, not just straight compatibility. Even if MS changed their target and broke their class library APIs tomorrow it wouldn't matter, because that's not what it's about. The real advantage to Linux application development can be seen in the GTK# project, which has no equivalent in the MS version of the CLR. GTK# and C# allow us to rapidly prototype and develop GUI's that we can use in typical Unix fashion to build tools out of smaller components. Personally I don't care if my C# apps run on windows on .NET. They will run wherever Mono runs. I believe that with GTK# and other gui libraries on Linux, C# fills the RAD niche far better than Java.
Anyway, all of these arguments have already been made against Mono and Miguel has effectively answered them all. Read the Mono FAQs. I don't believe that the Mono project will help Microsoft embrace and extend the web. Besides I don't see how a language runtime and a language itself will somehow magically subvert the net. Mono will support the Microsoft protocols (if they can be called that) that are openly documented.
We are at a critical juncture in our battle with Microsoft (to paraphrase Star Wars). The empire has made a critical error (in timing) and the time for our attack has come. With Longhorn delayed until 2006, we have an unprecedented (yes I like that word) opportunity to really polish and advance Linux, and I think C# and the Mono CLR can greately enhance Linux' position on the desktop, and on the server, as an alternative to server-side Java.
I'm amazed at how far Linux has come since the days in 1998 when I was first introduced to it, and I see in the next 2 years Linux going as far again as it did in the last 5 years. (SCO be damned.)
I've said this everytime an article on yet another embedded framebuffer attempt is posted. While embedded solutions like MiniGUI and QT/Embedded seem like great ideas, they both suffer from the same problems. First off, all though I love the GPL and wish that everything were GPL'd, in the case of the windowing system/widget set, the GPL is not appropriate. LGPL is more appropriate. Because the widget set is part of the windowing envirnoment, you can't write code under any other license for the environment, because it's GPL'd. This right away will limit MiniGUI's viability, because for most embedded developes, it will not be an option. QT/Embedded, of course can be purchased to avoid this issue.
Secondly, like all embedded framebuffer attempts, this one yet again reinvents the wheel, defining a windowing system, event-handling, input-handling and so forth. And of course only programs using that exact API can run on this environment. This is a significant restriction that I find rather suffocating when I am using OPIE on my Zaurus.
For many devices, including handhelds, the best solution is still venerable X11. Keith Packard's KDrive server is completely self-contained (font support, XRender support) and weighs in at just 700 kb. Run a lightweight environment such as matchbox on top of that (wonderful window manager designed for handhelds) with a nice light widget set, and you have all the same features as this MiniGUI without the restrictions it imposes. See what the gpe people have done with this. It's impressive. In such an X11-based environment, MiniGUI could be viable because it wouldn't exclude any other toolkits or APIs from being used.
The final problem I see with MiniGUI is that code appears more complicated and MS-ish than QT or GTK. Clearly the developers come from a win32 background, as MiniGUI code is full of win32-isms, which I find harder to program and less elegant than the Signal/Slot mechanisms of QT and GTK.
Clearly, with or without X11 you need to change the widget look and behavior from that on a desktop. The idea of "windows" becomes less important as full-screen is the only desirable mode. Modifying the input mechanism is also important. Things that we take for granted on desktops such as right-clicking don't translate well to a handheld. QT/E and gpe solve this by having the user hold his stylus on the widget for a couple of seconds to emulate the right-mouse-button-click.
There is no perfect system, and MiniGUI appears to be yet another attempt and I'm sure has a valid niche to fill. I wish them well.
The earth, everyone knows, was commissioned by the white mice as a great computer to compute the question to Life, the Universe, and Everything, for which the answer is 42, and was built by the custom luxury planet builders of Magrithea, although it was destroyed just before it had found the question.
... So what would happen was that the mice would run round mazes and things so that the whole nature of the learning process could be examined. From our observations of their behavior we were able to learn all sorts of things about our own...'
"'These creatures you call mice, you see, they are not quite as they appear. They are merely the protrusion into our dimension of vastly hyperintelligent pandimensional beings. The whole business with the chesse and the squeaking is just a front.'
The old man pause, and with a sympathetic frown continued. 'They've been experimenting on you, I'm afraid.'
Arthur thought about this for a seond, and then his face cleared.
'Ah no,' he said, 'I see the source of the misunderstanding now. No, look, you see what happened was that we used to do experiements on them.
Arthur's voice trailed off.
'Such subtlety...' said Slartibartfast, 'one has to admire it.'"
Having support in the kernel for devices and auto-detection and setup of those drivers are two different issues. Hardware detection and configuration (especially of removable devices) has been and should remain in user-space projects, such as hotplug, kudzu, and the Knoppix hardware detection routines. Most hardware devices need userspace support, anyway (such as setting up dev entries, modifying fstab etc).
One just need pop in a knoppix CD to see just how plug-and-play Linux really is. Most of the time it just works. Better than windows at times.
Building a detection routine into the kernel build process would be fantastic, though. How about taking this one step further. Have hotplug or some other monitoring program detect the new hardware, and if there's no driver already compiled, builds a module on the fly and loads it. A bit slow, but now slower than the windows wizard method for installing hardware. If you added the capability to have signed driver source code (and had a few locations of trusted code repositories, the program could go out and get the latest module code and try that.
This is not what the original poster was asking for. The kernel monte actually just does an effective reboot without going throug the bios. As I understand it, the kernel monte cannot tranfer running processes from one kernel to another. Last time I used it, the monte killed all my processes, and reloaded init (basically rebooting).
What the poster wants (and what I want) is the ability to load a new kernel, transfer the existing kernel tables (process, resource, driver status, etc) over to the new kernel and have things continue without interruption.
Michael
IE doesn't support flash either, and it's wide-spread. All you need is to embedd a link to the SVG active-X control and users will pick it up on the fly. No big deal. Average Joe's don't even know flash isn't supported natively. They still use it.
Don't look for any new features in IE for the next several years. By integrating it tightly into the OS and killing it as a standalone product, Microsoft has effectively eliminated all potential innovation in the browser area, since browser releases now equals OS releases. IE 7 won't be out until Longhorn (at least a year away), and even then it won't be widely used as most people will never migrate off XP for the life of their machines.
This is an unprecedented opportunity for Mozilla to win the browser war. Being a standalone installable app (that can run on win98 and up), Mozilla can add new features and support new standards. Just spread the word. Tell your friends. Talk to your favorite web developers.
Since xen is really a machine monitor, not an operating system, you won't be able to simple cut and paste between them. However, there are a number of utilities out there that can link clipboards (windows and linux) over a network connection. One example is MpCb, at http://www.idata.sk/~robo/mpcb/.
With software like MpCb, and if Xen supports virtual terminals, you could easily switch back and forth between, say XP and Linux. I know our CS computer labs would love that.
Depending on how flexible Xen is, one could run two video cards, keyboards, and monitors, and have completely separate terminals and OS's running on e one machine. This is seriously cool.
I've only had experience with the H-ITT device (http://www.h-itt.com). It's IR and has lots of problems when everyone uses it at once. Based on my experience with this, I think some kind of rf-thing is better. Perhaps some like of 802.11 or something that can handle overlapping requests.
For any that are interested, I've reverse-engineered the serial line protocol for H-ITT, which would allow one to write their own clients for the hardware. H-ITT only gives out the software for Windows, and dispite the academic demand refuse to develop for Macintosh, so we are working on a Mac app for our faculty.
This is a well-documented problem with XP and 2000 when service pack 4 is installed. Besides setting the registry entry "RequireSignOrSeal" to "0," you must run the "mmc" program, add a "Group Policy" Snap-in, then in there find and option that says something about ignore permissions on roaming profile. Set that to "enabled." I'm not yet at work, but when I get there, I'll get the exact key name and post it here. A quick search of google reveals it's not terribly obvious, although I found this before.
The interesting thing about the 49G (not the new 49G+) is that is based on the same Saturn processor that the 48G series was. 4mHz RISC with special 64-bit registers (to hold floating point numbers) and a 4-bit memory bus (but a 20-something-bit address space I think). However the 49G run something like 10 times faster than the 48G. This is due entirely to optimizing the operating system and rom routines. Amazing what optimization at the assembler level, when done properly, can do.
I expect the same issues to remain with redhat fedora. However under redhat fedora linux you can just apt-get dist-upgrade every year or so. For a workstation, this the best way, anyway. For a server, RedHat's really pushing for their slower-moving enterprise product which will have much longer lifespan.
What I'm doing with my old venerable redhat 6.2 server is taking relavent rh 9 security patches (sendmail an openssh to name two) and recompiling them for rh 6.2 In most cases, it's just a matter of tweaking the the spec file a bit (rh's openssh rpm still has build options for 6.2 that I can turn on) and spitting out some patched rpms.