A theming tool wouldn't require intervention of the KDE or Gnome developers. You're never going to get them to look exactly the same [I think] or behave exactly the same just through theming, but if it was easy to make a theme that was mostly consistent across the different widget sets you use, it'd be more attractive to mix and match.
As for a scriptable interface, I was thinking it would be simple enough to capture and manipulate calls to the GUI libraries, but that's not enough. For example, clicking on a button may bring up another menu or dialog box, and you won't be able to get that information just catching those calls. So it does need mostly a new paradigm. Or, as many applications have done [Emacs, Autocad, Maple, MagicVLSI?] make all features command line based and make the GUI and keybindings call the command line functions. That way you could separate the interface much like you can define your emacs macros.
This is, of course, the beautiful thing about CLIs in general- they are easy to extend. You can do great things with a GUI if you have a good CLI base. But I guess you didn't need me to tell you that:P
[Just quickly, in response to the first two paragraphs, I think that's pretty much what/proc is for. It makes a lot of interfacing with the kernel simple.]
As for your library for working with a bunch of environments, I had the contrapositive idea a while back: hear me out. A tool to theme Qt, GTK, and your Window Manager as similar as possible. That way, it wouldn't matter what programmers developed for, because it would all look the same on your system. That's a lot easier than trying to unify different widget sets and the like with an extra interface.
+kudos on the configurable controls, key bindings, macros and scripting for the GUI interface- I think we will head in that direction soon enough. Maybe you should write some small example patches for Qt or GTK?
I've never seen a PDF viewer anywhere that is quite as bad as Adobe's. Even on Windows it is flaky. When in Windows, I sincerely miss the Document Viewer that comes with Gnome. How large are we talking about? 2000 pages plus? I don't have many documents with more than 500 pages, so I'm not really sure what kind of size you mean.
I love the rest of your ideas, by the way. While MIDI support on Linux is fairly good now, I think we will take a few more years to surpass Windows as the musician's choice. None of the MIDI editors, for example, tickle me right now; but that is no one's fault but my own. Time to get hacking:)
I seem to somehow missed that you'd said common program preferences, so I apologize. Those really should be accessible via the GUI. Weather text file or GUI though, options should always be easy to understand. I've got a pretty serious gripe with Firefox's "about:config". Very few of those options are self documenting.
If I had millions in the bank and a large team of clever, experienced programmers, I'd point them at topics like:
X is fat. X.org is working on Modularisation now, but there's a while to go. It could sure use some more programmers. And then, I bet it could be a lot more useful too. Quartz showed us that X could have more features, I think we could push that idea to a new level.
Firefox. I heard someone speaking about having different processes for different second level domains, and different threads for each tab within, as well as one for the main gui of course, and one for the download box. I think that's a worthy cause, among other things. There are a lot of other usability things that need to be looked at, and a better caching algorithm.
The Hurd and the microkernels that it runs on. The feature list and the ideas coming out of those development circles blow my mind. Personally, I think this is where I'm going to focus my energy soon.
Various usability tweaks, such as unification of GUI, CLI, and keybinding.
Linux desktop market share is usually placed between 0.7-3.0%.
Microsoft could easily write apps for Linux, the license doesn't forbid that at all. It just forbids people taking the OS, sticking a GUI/DRM/etc on it, and selling it back to you.
Look, sakusha, it looks like Linux isn't for you. If you want OSX, use OSX. If you want the most popular operating system [because that seems like the metric you favor], use Windows. If you want a reliable operating system that works well and won't be made propriety next week, if you want an operating system that you can modify and contribute freely to, GNU/Linux is the obvious choice. This is its most important feature, wherever it lacks technically it can be fixed by any interested party, but one thing is assured to you: it is free. Everything else is just implementation detail.
I've got some thoughts on usability options too. I'd really like to have Emacs-y editing in text boxes in Firefox. Also, I think anywhere you are finding a file, you should be able to press down to have possible completions. Bash completion is ok, but confusing, especially when you're doing pathnames in quotes because they have spaces. And then, that doesn't work from the Gtk saveas or open boxes.
Be nice if the Xterm could inline render LaTeX, ps, pdf etc too:) I think that's asking too much though.
I keep hearing this. I remember reading ESR's essay on how horrible it was, long before I installed my first free operating system. But you know what? It was very easy to set up. I'd say it was less than thirty seconds to set up all of my printers [neither really popular, neither really recent, one is USB though] and print the test pages. I find it hard to believe that foomatic gui could be hard to use.
any more difficult than finding the menu that lets you make the change and clicking the button? I think people will get used to text config files, and soon it will be GUI configuration tools that feel dated.
No, I'd have to agree with the GP. An application I used to use at my last job would crash when docking toolbars, opening dialog boxes in some circumstances, etc. There are a lot of FIXMEs and missing functionality throughout WINE. Sure, it works, sometimes, and with some fiddling you can get applications to mostly work, but I'd agree that it does need a lot of work itself.
We don't even have a USB driver yet. The Hurd really could use some more coders. That said, it looks like it's coming along nicely. Markus is porting the Hurd to L4, but the Coyotos team is working pretty slow, they seem to be focusing on the CapIDL more than anything [which makes sense I guess, otherwise we would have a kernel we couldn't write anything for]. I don't think it'd take many more developers to get it up to Linux' standard, to be honest, so we really need to generate more interest in the hacking community. I mean, what is more romantic than microkernel hacking? Especially when it's something as forward thinking as Hurd-on-Coyotos.
Those are some serious specs! Still, the system in TFA has a peak theoretical floating point performance higher than that of the largest SGI system ever built, in graphics hardware alone.
In 48 bit colour:) It's difficult finding pre-origin-3000 information on high-end sgi systems.
IR4 is a funny thing. IIRC, both the Onyx 2 and Onyx 3000 supported it, and with the same performance, however, the Onyx 3000 took up twice the floor space:) You would think, with modern technology, we'd almost have an entire IR4 pipe on a couple of cards, and SGI back in the graphics market.
By the way, if you think the pixel count of Onyx IR4 was impressive, do you recall how many polygons it could render per second?
I remember reading some of the patents they got for this a few months ago. I'm pretty sure we've talked about this before, too. That's not to say I'm any less excited- when we start to see this technology applied to inter-core busses, we'll see latency drop low enough to integrate a bucketload of cores on a single die.
Good job. I tend to think in terms of Godel's first incompleteness theorem and the surrounding body of work; if we could prove or disprove the existence of some god, we would have to question the axioms we used to formulate such a proof. We don't know the fundamental axioms of this universe, and so it seems we have no call to reason about anything metaphysical at all.
Xen was really the driving force requiring hardware virtualisation technology, so it's no surprise they used such a feature. Yet it's funny to think that it takes less effort to switch operating systems than it does to switch tasks. Really that's only half true- it wouldn't be difficult to get a hypervisor to provide calls to manipulate ASIDs, it's just that you can't get that functionality from the kernel itself, which seems a bit silly. I guess what I'm trying to say is, if any kernel wanted to use the tagged TLB, they would have to start their own hypervisor, unless they had the good fortune of running on a hypervisor that had calls to manipulate the ASIDs from kernel space. As you can see, it mightn't be trivial to implement on most kernels, and it requires assumptions about the VM [or lack thereof] that the operating system is running on.
What I'm more cuious about is what this will do to the AIX market. Very interesting question. How do the two compare? If Solaris is indeed superior, maybe IBM are getting a cut from Sun, too..
Oooh- interesting. I had a look at the system programmers manual and it is a little light on details- being part of the SVM extensions, it might not be possible to use them from ring 0, which is a shame because it can't be used for general context switching, and even if it were, I don't think we will see the major operating systems use them.
The third choice, of course, is portable software. I don't think the time is QUITE right for that kind of jump, but you can be reasonably sure that if the Itanium or Alpha were released next year, they would sell a lot more units then they did before we really had [software] choice.
Sure- the x86 doesn't flush global [kernel] entries by default. As for the rest, I think TheRaven64 said it a lot better than me:
x86 does not have a tagged TLB. This means that every context switch needs a full TLB flush, which results in a lot of TLB (and cache) churn. On something like SPARC, you just set the process ID register, and TLB entries belonging to other processes become invisible.
AMEN! The lack of general purpose registers is a serious drawback to x86. The MMU is the same- well, it's not that it isn't feature packed, but it's so slow that we need a TLB, and the TLB can't handle threads, so all non-globals need to be flushed when context switching. Yuck.
All the other features the GP mentioned, except for the last one if you mean COMPILED code, are also available on most RISC chips:P and the performance data really spoke for itself [Alphas had four times the floating point performance of the Pentium II clock for clock].
Slashdot Mirror
What are you thinking of?
A theming tool wouldn't require intervention of the KDE or Gnome developers. You're never going to get them to look exactly the same [I think] or behave exactly the same just through theming, but if it was easy to make a theme that was mostly consistent across the different widget sets you use, it'd be more attractive to mix and match.
:P
As for a scriptable interface, I was thinking it would be simple enough to capture and manipulate calls to the GUI libraries, but that's not enough. For example, clicking on a button may bring up another menu or dialog box, and you won't be able to get that information just catching those calls. So it does need mostly a new paradigm. Or, as many applications have done [Emacs, Autocad, Maple, MagicVLSI?] make all features command line based and make the GUI and keybindings call the command line functions. That way you could separate the interface much like you can define your emacs macros.
This is, of course, the beautiful thing about CLIs in general- they are easy to extend. You can do great things with a GUI if you have a good CLI base. But I guess you didn't need me to tell you that
[Just quickly, in response to the first two paragraphs, I think that's pretty much what /proc is for. It makes a lot of interfacing with the kernel simple.]
As for your library for working with a bunch of environments, I had the contrapositive idea a while back: hear me out. A tool to theme Qt, GTK, and your Window Manager as similar as possible. That way, it wouldn't matter what programmers developed for, because it would all look the same on your system. That's a lot easier than trying to unify different widget sets and the like with an extra interface.
+kudos on the configurable controls, key bindings, macros and scripting for the GUI interface- I think we will head in that direction soon enough. Maybe you should write some small example patches for Qt or GTK?
I've never seen a PDF viewer anywhere that is quite as bad as Adobe's. Even on Windows it is flaky. When in Windows, I sincerely miss the Document Viewer that comes with Gnome. How large are we talking about? 2000 pages plus? I don't have many documents with more than 500 pages, so I'm not really sure what kind of size you mean.
:)
I love the rest of your ideas, by the way. While MIDI support on Linux is fairly good now, I think we will take a few more years to surpass Windows as the musician's choice. None of the MIDI editors, for example, tickle me right now; but that is no one's fault but my own. Time to get hacking
I seem to somehow missed that you'd said common program preferences, so I apologize. Those really should be accessible via the GUI. Weather text file or GUI though, options should always be easy to understand. I've got a pretty serious gripe with Firefox's "about:config". Very few of those options are self documenting.
- X is fat. X.org is working on Modularisation now, but there's a while to go. It could sure use some more programmers. And then, I bet it could be a lot more useful too. Quartz showed us that X could have more features, I think we could push that idea to a new level.
- Firefox. I heard someone speaking about having different processes for different second level domains, and different threads for each tab within, as well as one for the main gui of course, and one for the download box. I think that's a worthy cause, among other things. There are a lot of other usability things that need to be looked at, and a better caching algorithm.
- The Hurd and the microkernels that it runs on. The feature list and the ideas coming out of those development circles blow my mind. Personally, I think this is where I'm going to focus my energy soon.
- Various usability tweaks, such as unification of GUI, CLI, and keybinding.
- Next-gen file systems!
- ...
- Profit!
I'm sure there is a lot more..Linux desktop market share is usually placed between 0.7-3.0%.
Microsoft could easily write apps for Linux, the license doesn't forbid that at all. It just forbids people taking the OS, sticking a GUI/DRM/etc on it, and selling it back to you.
Look, sakusha, it looks like Linux isn't for you. If you want OSX, use OSX. If you want the most popular operating system [because that seems like the metric you favor], use Windows. If you want a reliable operating system that works well and won't be made propriety next week, if you want an operating system that you can modify and contribute freely to, GNU/Linux is the obvious choice. This is its most important feature, wherever it lacks technically it can be fixed by any interested party, but one thing is assured to you: it is free. Everything else is just implementation detail.
Nice suggestions!
:) I think that's asking too much though.
I've got some thoughts on usability options too. I'd really like to have Emacs-y editing in text boxes in Firefox. Also, I think anywhere you are finding a file, you should be able to press down to have possible completions. Bash completion is ok, but confusing, especially when you're doing pathnames in quotes because they have spaces. And then, that doesn't work from the Gtk saveas or open boxes.
Be nice if the Xterm could inline render LaTeX, ps, pdf etc too
I keep hearing this. I remember reading ESR's essay on how horrible it was, long before I installed my first free operating system. But you know what? It was very easy to set up. I'd say it was less than thirty seconds to set up all of my printers [neither really popular, neither really recent, one is USB though] and print the test pages. I find it hard to believe that foomatic gui could be hard to use.
I don't get it. How is changing:
option 1: true
to
option 1: false
any more difficult than finding the menu that lets you make the change and clicking the button? I think people will get used to text config files, and soon it will be GUI configuration tools that feel dated.
No, I'd have to agree with the GP. An application I used to use at my last job would crash when docking toolbars, opening dialog boxes in some circumstances, etc. There are a lot of FIXMEs and missing functionality throughout WINE. Sure, it works, sometimes, and with some fiddling you can get applications to mostly work, but I'd agree that it does need a lot of work itself.
We don't even have a USB driver yet. The Hurd really could use some more coders. That said, it looks like it's coming along nicely. Markus is porting the Hurd to L4, but the Coyotos team is working pretty slow, they seem to be focusing on the CapIDL more than anything [which makes sense I guess, otherwise we would have a kernel we couldn't write anything for]. I don't think it'd take many more developers to get it up to Linux' standard, to be honest, so we really need to generate more interest in the hacking community. I mean, what is more romantic than microkernel hacking? Especially when it's something as forward thinking as Hurd-on-Coyotos.
I actually meant this, but that is actually 50% more powerful. Still, it's on the same order.
Those are some serious specs! Still, the system in TFA has a peak theoretical floating point performance higher than that of the largest SGI system ever built, in graphics hardware alone.
In 48 bit colour :) It's difficult finding pre-origin-3000 information on high-end sgi systems.
:) You would think, with modern technology, we'd almost have an entire IR4 pipe on a couple of cards, and SGI back in the graphics market.
IR4 is a funny thing. IIRC, both the Onyx 2 and Onyx 3000 supported it, and with the same performance, however, the Onyx 3000 took up twice the floor space
By the way, if you think the pixel count of Onyx IR4 was impressive, do you recall how many polygons it could render per second?
and here is the site for their research: http://techresearch.intel.com/articles/Tera-Scale/ 1419.htm
I remember reading some of the patents they got for this a few months ago. I'm pretty sure we've talked about this before, too. That's not to say I'm any less excited- when we start to see this technology applied to inter-core busses, we'll see latency drop low enough to integrate a bucketload of cores on a single die.
Good job. I tend to think in terms of Godel's first incompleteness theorem and the surrounding body of work; if we could prove or disprove the existence of some god, we would have to question the axioms we used to formulate such a proof. We don't know the fundamental axioms of this universe, and so it seems we have no call to reason about anything metaphysical at all.
Xen was really the driving force requiring hardware virtualisation technology, so it's no surprise they used such a feature. Yet it's funny to think that it takes less effort to switch operating systems than it does to switch tasks. Really that's only half true- it wouldn't be difficult to get a hypervisor to provide calls to manipulate ASIDs, it's just that you can't get that functionality from the kernel itself, which seems a bit silly. I guess what I'm trying to say is, if any kernel wanted to use the tagged TLB, they would have to start their own hypervisor, unless they had the good fortune of running on a hypervisor that had calls to manipulate the ASIDs from kernel space. As you can see, it mightn't be trivial to implement on most kernels, and it requires assumptions about the VM [or lack thereof] that the operating system is running on.
Sounds like you had a very liberal education
Oooh- interesting. I had a look at the system programmers manual and it is a little light on details- being part of the SVM extensions, it might not be possible to use them from ring 0, which is a shame because it can't be used for general context switching, and even if it were, I don't think we will see the major operating systems use them.
The third choice, of course, is portable software. I don't think the time is QUITE right for that kind of jump, but you can be reasonably sure that if the Itanium or Alpha were released next year, they would sell a lot more units then they did before we really had [software] choice.
x86 does not have a tagged TLB. This means that every context switch needs a full TLB flush, which results in a lot of TLB (and cache) churn. On something like SPARC, you just set the process ID register, and TLB entries belonging to other processes become invisible.
AMEN! The lack of general purpose registers is a serious drawback to x86. The MMU is the same- well, it's not that it isn't feature packed, but it's so slow that we need a TLB, and the TLB can't handle threads, so all non-globals need to be flushed when context switching. Yuck.
:P and the performance data really spoke for itself [Alphas had four times the floating point performance of the Pentium II clock for clock].
All the other features the GP mentioned, except for the last one if you mean COMPILED code, are also available on most RISC chips