No, the true danger of a software monoculture is no derivatives at all.
Have you considered making your own distro? One of the reasons people copy these distros is that all the HARD work is already done. Once you have tracked down the bug, and fixed it, you can burn your own distro based on the original, but with the fix added. Then you could post it on Slashdot and become instantly famous (instead of just cowardly anonymous).
One really impressive 'tiling' WM is qlwm. Based on Qt, ironically enough. What is impressive about it is that you can switch seamlessly between normal "floating" window mode, tiled mode and fullscreen mode. Tiled mode has one window large (almost full-screen), the rest as smaller windows down one side. A single mouse click to make another window the large one. You can choose the mode on the fly, depending on the situation: fullscreen -- floating -- tiled. qlwm remembers each window's original size when you "un-tile", so you don't loose anything by swapping mode.
Of course, you could get this happening in fvwm as well.
Re:License confusion does not inspire confidence.
on
Xfce 4.2.0 Released
·
· Score: 1
Excuse me for living, but isn't licencing an important issue. Legally. At least we know you are a yank. yanker. Don't you think Microsoft or Apple take licencing seriously? Are they Canadian too?
".. actually windows covering the true root window."
For me, this creates a real annoyance. You see, I run fvwm, not Gnome or KDE. However, occasionally I use Gnome or KDE apps. For example, I might start up the gnome panel, and then choose "Home Folder" or whatever. Or I might just start up "nautilus" from the command line. Problem is, nautilus by default ALSO starts up the desktop. So much for the UNIX philosophy of each app does one thing really well. So now, I have a huge unwanted and unrequested window clogging up my background, one which doesn't close when nautilus closes, and which has to be shot with the -9 bullet before it finally dies. Not only that, just imagine how a full-screen window acts when you have AutoRaise enabled. What a pain. Oh, should have guessed that I need to use the "--no-desktop" option when I start the filemanager.
".. window managers are lacking something as basic as a desktop" Hmmm, now why would that be?
Maybe a window manager is for managing windows. Maybe a you need a desktop environment to get a desktop.
Sarcasm aside, it WOULD be possible to get drag and drop even from a window manager but it would require:
integrated drag and drop functionality
a purpose-built desktop application (yes, the "desktop" is really an application) that supports drag and drop.
a purpose-built filemanager that supports drag and drop.
menus and any other bits and pieces to support drag and drop.
Don't know about you, but that is beginning to sound more like a desktop environment than a window manager.
To you a desktop is basic. But doesn't the lack of "something as basic as a desktop" on so many other window managers AND desktop environments say something about how basic it really is?
If it looks like MS Windows, and it feels like MS Windows, then it probably stinks like MS Windows.
You can get individual still shots by using a command-line screendumper (xwd is one, there are others). Just write a script that continuously makes screen dumps and saves to numbered files. Make your animation from the still shots. (You might need to use something like xwdtoppm | ppmtojpg to convert the image format first).
The resulting 'animation' is not particularly smooth, however, and the cursor is not visible. I also found that xpaint screwed up the screendump when it was present.
Hey, AmiWM is already perfect, what more do you want? A menu that actually has something in it?
.. in the previous threads, people have been talking about how 'snappy' various desktops and window managers are. If you want snappy, try AmiWM.
Re:One reason why I'm still using Window Maker....
on
Xfce 4.2.0 Released
·
· Score: 1
I don't think the poster is talking about graphics.
Desktop environments have a lot of 'behind the scenes' stuff going on, for example they support drag and drop and so on. The KDE desktop and the KDE apps have a lot of integration going on. I don't remember all of it - but there is a lot there. It doesn't matter if you run only the desktop or only one of the apps, a whole lot of services get started up. That is the kind of heavy lifting being talked about. Hardware acceleration won't help.
2. Those amazing menus. Depending on what you initially do with the mouse they either disappear immediately, stay open until you click somewhere, or stay open permanently in the position you left them - including the next time you log on. Not only that, you can slide them down to the edge of the screen (bottom or side) so only a little bit is showing, and they become pop-up! Just hover the mouse over the bit that's showing and the menu just slides in from the side, or bottom - wherever you left it - and slides back again after use. This kind of attention to detail is brilliant.
3. Simple, strong visual design (relates to Point 1.)
4. Fast and light.
Re:How lightweight, if it requires gtk+?
on
Xfce 4.2.0 Released
·
· Score: 1
twm is so cool.:)
Used to be you could count on twm being available. So I was kinda sad when I discovered that Ubuntu doesn't ship with twm:( Must have wanted to save space or something.
When you want a fast, configurable, bitmap-oriented wm (and don't we all?), twm rules.
Re:How lightweight, if it requires gtk+?
on
Xfce 4.2.0 Released
·
· Score: 1
Actually, heliwm is as light as you can get, and pretty easy to use once you've learned it.;)
ION is not restricted to fullscreen, you can split screens horizontally and vertically to create all sorts of tiles. I found it got pretty messy, though, since it's all keyboard bindings. You might be able to set up default layouts in your config file.
Re:How lightweight, if it requires gtk+?
on
Xfce 4.2.0 Released
·
· Score: 1
The XFce I have at home uses Gtk for its panel. Haven't used it much, but from memory, without the panel, you would just have a pretty ordinary kind of window manager. Not sure about XFce4.
I may be wrong on this, but I think that drawing the image is not the only overhead of Gtk. Gtk has a pretty sophisticated language behind it and a lot of functionality. Having said that, I do notice that some gtk themes are slower than others, so if speed is what you want, then just choose a fast theme. I got the impression that space was a factor for the original poster.
Maybe you could start with something like fltk, and create a whole lot of dummy bindings to it to so it has the gtk api, or start with gtk and prune savagely.
I don't really see the benefit. If you look at the modern desktop, the apps themselves tend to have a lot of bloat - which implies that the widget toolkit is not a huge factor. Most applications have smaller, lighter, non-gtk equivalents - just look at Damn Small Linux. And many of those apps have been around for years.
The idea of a Gtk-- has some superficial appeal, but I wonder how useful it would really be. You already have lightweight toolkits, lightweight applications, lightweight distributions and lightweight gtk themes. I read somewhere about a KDE-based distro that had hard-wired Qt somehow so that all the apps loaded really fast. That worked because the distro developers went to a lot of effort, and controlled the applications on the distro. Something like that could benefit from something like Gtk--. But, again, why not go for Damn Small Linux - it already exists.
Re:How lightweight, if it requires gtk+?
on
Xfce 4.2.0 Released
·
· Score: 1
Let me get this straight.. You want a good WM without gtk+ or Qt. Repeat GOOD. don't like wmaker - or its ilk (!). "a little modern" Oh, and I hate Debian.
I suggest you write your own.
There are over 50 wms available for Linux and most of them are better than the Windows WM, which is the global standard. Many of them can be customised to your hearts delight.
If it weren't for your attitude, I would have suggested fvwm, since it is lightweight and can be configured to look and feel pretty much anyway you could possibly imagine. As it is, I think you're on your own.
fvwm supports mouse guestures. You describe the mouse guesture and the fvwm command that it will bind to. fvwm commands can include running shell commands or scripts. Thus you can do all your window management, and workspace management, as well as launching any application or running any fancy script you happen to have written (eg to do configuration stuff) using mouse guestures. You can also make the bindings sensitive to which area of the screen, window, window-decoration, titlebar-button etc etc, and (if in a window) what application that window is - and lots of other tests too. (eg: if [user] draws an F in a 250x250pixel box near the top lefthand area of the root window then launch Firefox. If [user] does Ctrl-draw an X inside a window, and it's a Firfox window, then kill the window). If you want, you can change bindings on the fly (modal bindings anyone?)
Not only that, but fvwm has the ability to monitor, report and respond to different types of mouse/window/windowmanager events PLUS accept and execute arbitrary commands dynamically from ANY application or script - that knows what commands to send:) - or interactively from any shell. (read the manpages for FvwmEvent, FvwmAuto, FvwmCommand and so on.)
If you really really really want the functionality you have described, and are not afraid of doing some reading, learning and config-file editing, then I think your dream world already happened. Give yourself a few weeks to work through the manpages;)
If you were really into it, you might also be able to get Mozilla and family to come in on the act using XUL. Definitely, you could control any tcl/tk apps you have lying around using fvwm (and vice-versa!).
The only window manager I know that can send keyboard events and mouse events to any application window is gwm, but gwm doesn't support mouse guestures as far as I know - unless you want to write the code yourself in lisp. Sawfish seems to have a lot of low-level commands, maybe it can be made to do what you want also.
You mention the concept of "something like a simple text editor, where you can move around in a "document" and press Enter at any time, with the output always appearing below it"
I first wrote an editor like this in 1985, using Forth on a C64. In 1988 I implemented it using APL on a mainframe, later using CPM/VM (???), xedit and REXX. I implemented it using Java and an invented language called Dork (which might appear on Sourceforge eventually), and when I migrated to Linux I had a shot at getting it working by piping Dork stdout into bash.
All of these environments not only allowed you to "press Enter" at any point to execute the text, but also allowed you to organise the "document" as a heirarchical tree of pages with arbitrary hyperlinking between each page (again, just "press Enter").
This is without a doubt the most powerful way of working that I have ever used, and I miss it greatly in my day to day work. Remember, that these environments are first and formost text editors, so you mix text (documentation, comments etc), commands and output as you see fit. You only differentiate when you want to execute something. You don't need to swap to another mode, or type:!ls (or whatever), just "point and click".
Bash history is NOT the same thing. History is strictly sequential and chronological, an edited document is organised by task or subject matter, hence the commands you find there are related to that task or subject.
All the flack you got was from people who simply did not get what you were talking about. Maybe also because you rubbished one of the most powerful tools in the linux/unix/gnu world - the shell.
Also, you got a comment like "just go hack the source code yourself". Well, easier said than done. I recently had a look at xterm code to do what I thought would be a simple change. No way! The code even had comments like "If you think you understand this code, you don't" Even the maintainers weren't completely sure what was going on in the code! I wouldn't be surprised that bash is just as difficult - just look at the man page to see how complex it is! Sometimes good ideas come from people who are not capable of implementing them.
I realise that emacs could do this, but I have not got into emacs enough to make it happen. I got introduced to vi quite early and find emacs really annoying to use, so haven't yet tackled what is yet another learning curve (linux has so-o-o-o many of them!) to get emacs to work in the way you describe. So I keep looking at different linux-based technologies (emacs, tk, mozilla, curses, parrot..) thinking "could I use this to make [your/my] idea work - and how much work is it really?". Even considered the gwm window manager - that may still be the key. Anyhow...
What I really want to say is this:
I have tried this idea in real life to do real work, and it made my work a whole lot easier. It IS a good idea, but it is a whole different conceptual model from the line-by-line mode that CLI shells normally use. Therefore most people will probably not understand what is being described, or why it is such a powerful concept.
".. is usually a wrapper still reading and writing text files behind the scene."..
This used to be the case. Erik Raymond in "The Art of Unix Programming" says that decision to make everything a TEXT file was made consciously very early in the piece. Together with the tool set (lots of text-based filters and stuff) this made for very powerful CLI environment. Pretty much any aspect of the machine could be controlled by editing or generating human-readable text. (Also, no need for purpose built "editors" like RegEdit)
My understanding is that in the recent rush to be more like Windows, some of that has gone backwards. Some config files are now gzipped or jarred, and often it is really really hard to track down where those (text or otherwise) files actually are. Also, more and more there is no CLI application to start with, it's just all coded up from C libraries. This, I think, is a shame - and definitely a step backwards.
Another aspect mentioned by Raymond is that it is much cheaper (cpu cycles and memory) to start processes under Linux or Unix than under Windows. This has led to a situation where the Windows environment encourages bloated do-everything blackbox applications, whereas Unix/Linux encourages lots of little do-one-thing-well tools. This is part of the reason that GUIs are able to be written as wrappers to CLI apps. It also means that it is easy to write your own wrappers - since all the raw materials and tools are readily available and easy to use.
A third part of the Unix vs Windows CLI equation comes about because of the decision to the tools compatible with each other and with pipes. One aspect of this is that most of the GNU CLI toolkit enables piping in and out. The Unix pipes would be pretty useless if there were no tools to pipe to or from! Another aspect is the rule about "If you have nothing to report, don't report anything". This means that the text that comes from one tool isn't cluttered with white noise that needs to be filtered out before it can be processed by the next tool in the pipeline.
BTW, it seems from reading various Windows users' posts that Windows does have some powerful CLI environments after all. I honestly didn't know that. Still, I won't be changing over.
I recommend Erik Raymond's book even if you are not a programmer and don't use UNIX (or Linux). It has some very interesting comparisons between different approaches to operating system design. It really brought home to me exactly why Linux is such a great envirnment at the CLI level. It also has some interesting stuff regarding the relative merits of CLI vs Rogue vs GUI interfaces.
I don't use MS at all, but from what I have read and heard, the Windows command line, dos prompt, whatever is no match to the bash/GNU tools combination. Even the simple fact that pipes are sequential under Windows but concurrent (parallel) under Unix/Linux makes one hell of a big difference in power and possibility. A text-based prompt will look superficially similar no matter what, but the test is when you USE the damned thing. Maybe your 'REAL Windows Admin' knows how powerful the Windows command line is. Does he know how powerful the UNIX/Linux command line is? My understanding is that Windows doesn't have a REAL command line.
"Maybe one day we'll be able to simply "see" the word or line and it will be entered.."
You mean writing real code? You're joking, right? My guess would be that at some time in the first week my mind would form a very powerful and vivid image of a giant sledgehammer descending into the guts of the computer. It would probably take the rest of the week to mend the wreckage that would ensue:(
Maybe you are thinking of the computer that just has a single button to press. When you press that button, the computer does exactly what you want it to do. I actually have a computer like that. Whenever I press the button, it powers off.
You can definitely have both the KDE and Gnome panels running simultaneously. The KDE panel is an application called "kicker" and the Gnome panel is called "gnome-panel" or (in earlier versions) "panel". I don't use either Gnome or KDE as a desktop - I use window managers - but I occasionally open up one or other of the panels temporarily if I want access to their menus.
It can take a long time to learn fvwm2 because it has so much functionality and so many commands.
However, if you already know what you want your 'desktop' to look and feel like, and your.fvwm2rc file chain implements that, then your tweaking is at an end.
If you are always 'tweaking the config file to match your needs' then that implies that your needs are changing. Either you have a windowmanager that can keep up with your changing needs (eg. fvwm) or you don't. If you do, then you need to tweak the config files, if you don't then your 'desktop' doesn't satisfy your needs. I can't see how using fvwm would make your needs change faster than using any other window manager or desktop environment.
btw I use fvwm at work, and I have made one change to the config file in maybe nine months. I turned off the 'scroll to the next page when your cursor moves off the screen' - didn't work so well with full-screen apps that also had scroll-bars. Oh, maybe I 'tweaked' the main menu a few times too during that time.
Sorry to answer a joke/troll with a rant, it's just that fvwm is under-rated b/c most people have no idea what it's is capable of underneath that ugly default theme.
Every choice in the Linux world is a matter of personal style.
I am not disputing that the SQL you gave is more efficient than the corresponding Ruby, or that OO may be a poor paradigm to choose for querying a relational database.
But..
There is a saying.. "Premature optimisation is the root of all evil"
From where I stand (don't know Ruby, rarely use SQL) the Ruby example is easy to understand, and the SQL example is far from obvious. This is from someone that has never used Ruby but has used SQL.
The point is that unless some analysis shows that that particular piece of Ruby code causes an unacceptable bottleneck within the context of the application (from the point of view of the user), then stick with the code that is shorter, simpler, easier to write and easier to maintain.
I guess part of what you are saying is that there are existing (old) technologies that are better in some sense if only people would take the time and effort to learn about them, rather than chasing the flavour of the month. If that is part of your message then I whole-heartedly agree. I like fvwm!
>>> These are the kinds of lawsuits that drive up the costs of everything
maybe not.
for one, if you pay heaps for something that breaks after less than a year, then that is a cost too. Sometimes it is better (and cheaper) to pay more upfront in return for superior quality. (No, I am not saying that price = quality)
On the other hand, you are talking about a corporation that routinely overcharges (80% markup is what I heard) on their software, and makes a loss selling the XBox. Seems to me the courtcase will have zero effect on the price of the consol.
If you are talking about the cost of games, I don't think the game stopped working after less than a year...
"Well then, 1. What's wrong with it? and 2. Who's doing it better?"
1. Huge security issues. customer lockin.
2. Nobody does huge security issues and customer lockin better.
But your second point is very telling, and shows up MisterShaft for what it really is. A Monopoly. You see, in a competitive capitalist consumer society, you don't have to 'do better', you just have to do 'about as well'. When my (
let's say) Sony CD player dies, I go out and buy a new (let's say) LG CD player to replace it. No worries, no problems. Maybe it's the other way round, and maybe it's completely different brands. The fact is that it is not that important, and I probably buy the first one I see that's around the right price, has the right features (plays CDs), and
looks okay.
Now if I was FORCED to replace it with another Sony player, because that was the only brand that can play my collection of Sony CDs -- THAT is vendor lockin. And if YOU were faced with that non-choice you would be pissed off. Well, guess what. I'm pissed off with MicroSoft for exactly the same reason. Only I do have a choice. I choose an operating system that has always done it better, and I make that choice at home as well as at work. Lucky me.
Slashdot Mirror
thanks
No, the true danger of a software monoculture is no derivatives at all.
Have you considered making your own distro? One of the reasons people copy these distros is that all the HARD work is already done. Once you have tracked down the bug, and fixed it, you can burn your own distro based on the original, but with the fix added. Then you could post it on Slashdot and become instantly famous (instead of just cowardly anonymous).
One really impressive 'tiling' WM is qlwm. Based on Qt, ironically enough. What is impressive about it is that you can switch seamlessly between normal "floating" window mode, tiled mode and fullscreen mode. Tiled mode has one window large (almost full-screen), the rest as smaller windows down one side. A single mouse click to make another window the large one. You can choose the mode on the fly, depending on the situation: fullscreen -- floating -- tiled. qlwm remembers each window's original size when you "un-tile", so you don't loose anything by swapping mode.
Of course, you could get this happening in fvwm as well.
Excuse me for living, but isn't licencing an important issue. Legally. At least we know you are a yank. yanker. Don't you think Microsoft or Apple take licencing seriously? Are they Canadian too?
".. actually windows covering the true root window."
For me, this creates a real annoyance. You see, I run fvwm, not Gnome or KDE. However, occasionally I use Gnome or KDE apps. For example, I might start up the gnome panel, and then choose "Home Folder" or whatever. Or I might just start up "nautilus" from the command line. Problem is, nautilus by default ALSO starts up the desktop. So much for the UNIX philosophy of each app does one thing really well. So now, I have a huge unwanted and unrequested window clogging up my background, one which doesn't close when nautilus closes, and which has to be shot with the -9 bullet before it finally dies. Not only that, just imagine how a full-screen window acts when you have AutoRaise enabled. What a pain. Oh, should have guessed that I need to use the "--no-desktop" option when I start the filemanager.
".. window managers are lacking something as basic as a desktop" Hmmm, now why would that be?
Maybe a window manager is for managing windows. Maybe a you need a desktop environment to get a desktop.
Sarcasm aside, it WOULD be possible to get drag and drop even from a window manager but it would require:
integrated drag and drop functionality
a purpose-built desktop application (yes, the "desktop" is really an application) that supports drag and drop.
a purpose-built filemanager that supports drag and drop.
menus and any other bits and pieces to support drag and drop.
Don't know about you, but that is beginning to sound more like a desktop environment than a window manager.
To you a desktop is basic. But doesn't the lack of "something as basic as a desktop" on so many other window managers AND desktop environments say something about how basic it really is?
If it looks like MS Windows, and it feels like MS Windows, then it probably stinks like MS Windows.
You can get individual still shots by using a command-line screendumper (xwd is one, there are others). Just write a script that continuously makes screen dumps and saves to numbered files. Make your animation from the still shots. (You might need to use something like xwdtoppm | ppmtojpg to convert the image format first).
The resulting 'animation' is not particularly smooth, however, and the cursor is not visible. I also found that xpaint screwed up the screendump when it was present.
I don't think the poster is talking about graphics.
Desktop environments have a lot of 'behind the scenes' stuff going on, for example they support drag and drop and so on. The KDE desktop and the KDE apps have a lot of integration going on. I don't remember all of it - but there is a lot there. It doesn't matter if you run only the desktop or only one of the apps, a whole lot of services get started up. That is the kind of heavy lifting being talked about. Hardware acceleration won't help.
This is what I like about WindowMaker:
1. All those jenspen themes on freshmeat
2. Those amazing menus. Depending on what you initially do with the mouse they either disappear immediately, stay open until you click somewhere, or stay open permanently in the position you left them - including the next time you log on. Not only that, you can slide them down to the edge of the screen (bottom or side) so only a little bit is showing, and they become pop-up! Just hover the mouse over the bit that's showing and the menu just slides in from the side, or bottom - wherever you left it - and slides back again after use. This kind of attention to detail is brilliant.
3. Simple, strong visual design (relates to Point 1.)
4. Fast and light.
twm is so cool. :)
:( Must have wanted to save space or something.
Used to be you could count on twm being available. So I was kinda sad when I discovered that Ubuntu doesn't ship with twm
When you want a fast, configurable, bitmap-oriented wm (and don't we all?), twm rules.
Actually, heliwm is as light as you can get, and pretty easy to use once you've learned it. ;)
ION is not restricted to fullscreen, you can split screens horizontally and vertically to create all sorts of tiles. I found it got pretty messy, though, since it's all keyboard bindings. You might be able to set up default layouts in your config file.
The XFce I have at home uses Gtk for its panel. Haven't used it much, but from memory, without the panel, you would just have a pretty ordinary kind of window manager. Not sure about XFce4.
I may be wrong on this, but I think that drawing the image is not the only overhead of Gtk. Gtk has a pretty sophisticated language behind it and a lot of functionality. Having said that, I do notice that some gtk themes are slower than others, so if speed is what you want, then just choose a fast theme. I got the impression that space was a factor for the original poster.
Maybe you could start with something like fltk, and create a whole lot of dummy bindings to it to so it has the gtk api, or start with gtk and prune savagely.
I don't really see the benefit. If you look at the modern desktop, the apps themselves tend to have a lot of bloat - which implies that the widget toolkit is not a huge factor. Most applications have smaller, lighter, non-gtk equivalents - just look at Damn Small Linux. And many of those apps have been around for years.
The idea of a Gtk-- has some superficial appeal, but I wonder how useful it would really be. You already have lightweight toolkits, lightweight applications, lightweight distributions and lightweight gtk themes. I read somewhere about a KDE-based distro that had hard-wired Qt somehow so that all the apps loaded really fast. That worked because the distro developers went to a lot of effort, and controlled the applications on the distro. Something like that could benefit from something like Gtk--. But, again, why not go for Damn Small Linux - it already exists.
Let me get this straight.. You want a good WM without gtk+ or Qt. Repeat GOOD. don't like wmaker - or its ilk (!). "a little modern" Oh, and I hate Debian.
I suggest you write your own.
There are over 50 wms available for Linux and most of them are better than the Windows WM, which is the global standard. Many of them can be customised to your hearts delight.
If it weren't for your attitude, I would have suggested fvwm, since it is lightweight and can be configured to look and feel pretty much anyway you could possibly imagine. As it is, I think you're on your own.
Have you looked at fvwm2 ???
:) - or interactively from any shell. (read the manpages for FvwmEvent, FvwmAuto, FvwmCommand and so on.)
;)
fvwm supports mouse guestures. You describe the mouse guesture and the fvwm command that it will bind to. fvwm commands can include running shell commands or scripts. Thus you can do all your window management, and workspace management, as well as launching any application or running any fancy script you happen to have written (eg to do configuration stuff) using mouse guestures. You can also make the bindings sensitive to which area of the screen, window, window-decoration, titlebar-button etc etc, and (if in a window) what application that window is - and lots of other tests too. (eg: if [user] draws an F in a 250x250pixel box near the top lefthand area of the root window then launch Firefox. If [user] does Ctrl-draw an X inside a window, and it's a Firfox window, then kill the window). If you want, you can change bindings on the fly (modal bindings anyone?)
Not only that, but fvwm has the ability to monitor, report and respond to different types of mouse/window/windowmanager events PLUS accept and execute arbitrary commands dynamically from ANY application or script - that knows what commands to send
If you really really really want the functionality you have described, and are not afraid of doing some reading, learning and config-file editing, then I think your dream world already happened. Give yourself a few weeks to work through the manpages
If you were really into it, you might also be able to get Mozilla and family to come in on the act using XUL. Definitely, you could control any tcl/tk apps you have lying around using fvwm (and vice-versa!).
The only window manager I know that can send keyboard events and mouse events to any application window is gwm, but gwm doesn't support mouse guestures as far as I know - unless you want to write the code yourself in lisp. Sawfish seems to have a lot of low-level commands, maybe it can be made to do what you want also.
Wow, you sure got a lot of reaction there!
:!ls (or whatever), just "point and click".
...
You mention the concept of "something like a simple text editor, where you can move around in a "document" and press Enter at any time, with the output always appearing below it"
I first wrote an editor like this in 1985, using Forth on a C64. In 1988 I implemented it using APL on a mainframe, later using CPM/VM (???), xedit and REXX. I implemented it using Java and an invented language called Dork (which might appear on Sourceforge eventually), and when I migrated to Linux I had a shot at getting it working by piping Dork stdout into bash.
All of these environments not only allowed you to "press Enter" at any point to execute the text, but also allowed you to organise the "document" as a heirarchical tree of pages with arbitrary hyperlinking between each page (again, just "press Enter").
This is without a doubt the most powerful way of working that I have ever used, and I miss it greatly in my day to day work. Remember, that these environments are first and formost text editors, so you mix text (documentation, comments etc), commands and output as you see fit. You only differentiate when you want to execute something. You don't need to swap to another mode, or type
Bash history is NOT the same thing. History is strictly sequential and chronological, an edited document is organised by task or subject matter, hence the commands you find there are related to that task or subject.
All the flack you got was from people who simply did not get what you were talking about. Maybe also because you rubbished one of the most powerful tools in the linux/unix/gnu world - the shell.
Also, you got a comment like "just go hack the source code yourself". Well, easier said than done. I recently had a look at xterm code to do what I thought would be a simple change. No way! The code even had comments like "If you think you understand this code, you don't" Even the maintainers weren't completely sure what was going on in the code! I wouldn't be surprised that bash is just as difficult - just look at the man page to see how complex it is! Sometimes good ideas come from people who are not capable of implementing them.
I realise that emacs could do this, but I have not got into emacs enough to make it happen. I got introduced to vi quite early and find emacs really annoying to use, so haven't yet tackled what is yet another learning curve (linux has so-o-o-o many of them!) to get emacs to work in the way you describe. So I keep looking at different linux-based technologies (emacs, tk, mozilla, curses, parrot..) thinking "could I use this to make [your/my] idea work - and how much work is it really?". Even considered the gwm window manager - that may still be the key. Anyhow
What I really want to say is this:
I have tried this idea in real life to do real work, and it made my work a whole lot easier. It IS a good idea, but it is a whole different conceptual model from the line-by-line mode that CLI shells normally use. Therefore most people will probably not understand what is being described, or why it is such a powerful concept.
" .. is usually a wrapper still reading and writing text files behind the scene." ..
This used to be the case. Erik Raymond in "The Art of Unix Programming" says that decision to make everything a TEXT file was made consciously very early in the piece. Together with the tool set (lots of text-based filters and stuff) this made for very powerful CLI environment. Pretty much any aspect of the machine could be controlled by editing or generating human-readable text. (Also, no need for purpose built "editors" like RegEdit)
My understanding is that in the recent rush to be more like Windows, some of that has gone backwards. Some config files are now gzipped or jarred, and often it is really really hard to track down where those (text or otherwise) files actually are. Also, more and more there is no CLI application to start with, it's just all coded up from C libraries. This, I think, is a shame - and definitely a step backwards.
Another aspect mentioned by Raymond is that it is much cheaper (cpu cycles and memory) to start processes under Linux or Unix than under Windows. This has led to a situation where the Windows environment encourages bloated do-everything blackbox applications, whereas Unix/Linux encourages lots of little do-one-thing-well tools. This is part of the reason that GUIs are able to be written as wrappers to CLI apps. It also means that it is easy to write your own wrappers - since all the raw materials and tools are readily available and easy to use.
A third part of the Unix vs Windows CLI equation comes about because of the decision to the tools compatible with each other and with pipes. One aspect of this is that most of the GNU CLI toolkit enables piping in and out. The Unix pipes would be pretty useless if there were no tools to pipe to or from! Another aspect is the rule about "If you have nothing to report, don't report anything". This means that the text that comes from one tool isn't cluttered with white noise that needs to be filtered out before it can be processed by the next tool in the pipeline.
BTW, it seems from reading various Windows users' posts that Windows does have some powerful CLI environments after all. I honestly didn't know that. Still, I won't be changing over.
I recommend Erik Raymond's book even if you are not a programmer and don't use UNIX (or Linux). It has some very interesting comparisons between different approaches to operating system design. It really brought home to me exactly why Linux is such a great envirnment at the CLI level. It also has some interesting stuff regarding the relative merits of CLI vs Rogue vs GUI interfaces.
I don't use MS at all, but from what I have read and heard, the Windows command line, dos prompt, whatever is no match to the bash/GNU tools combination. Even the simple fact that pipes are sequential under Windows but concurrent (parallel) under Unix/Linux makes one hell of a big difference in power and possibility. A text-based prompt will look superficially similar no matter what, but the test is when you USE the damned thing. Maybe your 'REAL Windows Admin' knows how powerful the Windows command line is. Does he know how powerful the UNIX/Linux command line is? My understanding is that Windows doesn't have a REAL command line.
"Maybe one day we'll be able to simply "see" the word or line and it will be entered.." You mean writing real code? You're joking, right? My guess would be that at some time in the first week my mind would form a very powerful and vivid image of a giant sledgehammer descending into the guts of the computer. It would probably take the rest of the week to mend the wreckage that would ensue :(
Maybe you are thinking of the computer that just has a single button to press. When you press that button, the computer does exactly what you want it to do. I actually have a computer like that. Whenever I press the button, it powers off.
You can definitely have both the KDE and Gnome panels running simultaneously. The KDE panel is an application called "kicker" and the Gnome panel is called "gnome-panel" or (in earlier versions) "panel". I don't use either Gnome or KDE as a desktop - I use window managers - but I occasionally open up one or other of the panels temporarily if I want access to their menus.
In your dreams.
.fvwm2rc file chain implements that, then your tweaking is at an end.
It can take a long time to learn fvwm2 because it has so much functionality and so many commands.
However, if you already know what you want your 'desktop' to look and feel like, and your
If you are always 'tweaking the config file to match your needs' then that implies that your needs are changing. Either you have a windowmanager that can keep up with your changing needs (eg. fvwm) or you don't. If you do, then you need to tweak the config files, if you don't then your 'desktop' doesn't satisfy your needs. I can't see how using fvwm would make your needs change faster than using any other window manager or desktop environment.
btw I use fvwm at work, and I have made one change to the config file in maybe nine months. I turned off the 'scroll to the next page when your cursor moves off the screen' - didn't work so well with full-screen apps that also had scroll-bars. Oh, maybe I 'tweaked' the main menu a few times too during that time.
Sorry to answer a joke/troll with a rant, it's just that fvwm is under-rated b/c most people have no idea what it's is capable of underneath that ugly default theme.
Every choice in the Linux world is a matter of personal style.
I am not disputing that the SQL you gave is more efficient than the corresponding Ruby, or that OO may be a poor paradigm to choose for querying a relational database.
But..
There is a saying .. "Premature optimisation is the root of all evil"
From where I stand (don't know Ruby, rarely use SQL) the Ruby example is easy to understand, and the SQL example is far from obvious. This is from someone that has never used Ruby but has used SQL.
The point is that unless some analysis shows that that particular piece of Ruby code causes an unacceptable bottleneck within the context of the application (from the point of view of the user), then stick with the code that is shorter, simpler, easier to write and easier to maintain.
I guess part of what you are saying is that there are existing (old) technologies that are better in some sense if only people would take the time and effort to learn about them, rather than chasing the flavour of the month. If that is part of your message then I whole-heartedly agree. I like fvwm!
maybe not.
for one, if you pay heaps for something that breaks after less than a year, then that is a cost too. Sometimes it is better (and cheaper) to pay more upfront in return for superior quality. (No, I am not saying that price = quality)
On the other hand, you are talking about a corporation that routinely overcharges (80% markup is what I heard) on their software, and makes a loss selling the XBox. Seems to me the courtcase will have zero effect on the price of the consol.
If you are talking about the cost of games, I don't think the game stopped working after less than a year...
"Well then, 1. What's wrong with it? and 2. Who's doing it better?"
1. Huge security issues. customer lockin.
2. Nobody does huge security issues and customer lockin better.
But your second point is very telling, and shows up MisterShaft for what it really is. A Monopoly. You see, in a competitive capitalist consumer society, you don't have to 'do better', you just have to do 'about as well'. When my ( let's say) Sony CD player dies, I go out and buy a new (let's say) LG CD player to replace it. No worries, no problems. Maybe it's the other way round, and maybe it's completely different brands. The fact is that it is not that important, and I probably buy the first one I see that's around the right price, has the right features (plays CDs), and looks okay.
Now if I was FORCED to replace it with another Sony player, because that was the only brand that can play my collection of Sony CDs -- THAT is vendor lockin. And if YOU were faced with that non-choice you would be pissed off. Well, guess what. I'm pissed off with MicroSoft for exactly the same reason. Only I do have a choice. I choose an operating system that has always done it better, and I make that choice at home as well as at work. Lucky me.
Easy.