I spent yesterday looking at eclipse CDT again. Basically the only feature I am interested in is 'content assist' - emacs rules it in every other way (for me). Unfortunately, that doesn't really work. I used the RPM available for Fedora 5 and it basically fails to index. Repeated problems failing to update project paths. After repeated failures trying to get CA to work, I tried to replicate the screen shot they show with 'mystruct' - that didn't work the first few times I tried it. Either something is badly wrong with the FC5 RPM or it isn't quite there yet. I'll check it out again in another year, but at the moment it still sucks for C/C++ Even if the 'content assist' feature worked, it still needs a good indent engine and to make better use of screen space. I wasn't able to see much code even when maximized - looked to be due to extra spacing between lines of code.
If only the CEDET package for emacs actually worked...
Re:Shoot me for my ignorance...
on
Sin City Trailer
·
· Score: 2, Informative
He also wrote the best Daredevil stories. He created Elektra (which will probably be another horrible movie) and IIRC Bullseye as well. Some of the Robocop movie scripts (which I could have left out) were written by him as well.
Network transparency can easily be provided by modern component object models like GNOME's Bonobo and KDE's Kparts, with the added bonus that clients are thin and so still usable over a high-latency network.
This is an amusing and rather bad idea.
Currently both GNOME and KDE achieve network transparency by virtue of using the X Window System. Also, there are a lot of X applications that don't use either of those object models: straight Qt/Gtk+, Tk, Xlib, Xt/Xaw/Motif, etc. There are too many for me to bother listing here.
Even if the only apps that mattered were GNOME and KDE apps (most definitely not the case), this would be a really bad idea.
Both GNOME/KDE (really Gtk+/Qt) need an underlying graphic system. That system still needs drivers for all the video cards of interest. Somebody has to write those drivers.
Instead of using a simple, common proven technology (X11 protocol) to achieve network transparency, you suggest switching to two separate technologies that were designed for something completely different (components).
How exactly will Kparts and Bonobo achieve this magic feat anyway? I admit that I am not too familiar with either of these technologies. However, I believe they basically allow a program to use components which can be instantiated either in process (via shared libraries) or in another process (via remote procedure calls using RPC/CORBA or something similar). Nothing about them says network transparent graphics. How do I display a program running on a SPARC workstation on my x86 PC using these technologies? Or one running on an x86 PC running Linux or BSD and displaying on an x86 PC running MS Windows? Please enlighten me. I am sure Microsoft would be interested in doing it with OLE/COM/ActiveX/whatever as well.
I wouldn't go so far as to call XFree86 obsolete, but the technologies upon which it's based certainly are.
What part of them do you consider obsolete? I haven't heard of anything obsoleting client/server architectures. For that matter, the X11 protocol is really nothing more than an asynchronous remote procedure call (see CORBA/RPC). I wasn't aware that those were obsolete either.
While there are some problems with the X Window System, they won't be solved by a mass switch to Kparts/Bonobo.
... could someone please provide a brief history of what the watcom compiler is or does differently than other compilers, and why it's suited to making DOOM-type games where other compilers aren't?
IIRC, it came with a DOS extender that allowed the creation of programs with a flat 32 bit address space. This was very useful, as at the time programmers were still dealing with segments on x86 (limiting arrays to 64K, etc).
Re:ok, make your case objectively?
on
VIM 6.0 is Out
·
· Score: 1
There are ways to create FTP 'filesystems' (OS/2 was doing it in 1994ish?) Failing that, you can easily write an external script and bind it to a macro in the editor.
That is exactly what emacs does. It uses a script (originally ange-ftp, not sure what it is now). It actually launches an ftp client and issues commands to it in response to your key presses.
People think that emacs is bloated, but that is a misconception. It is true that it is larger than vi, but the largest portion is due to preloaded scripts. An emacs binary contains a large amount of initialized data (generated from emacs after loading many packages). While it isn't worthwhile, you could build a smaller emacs with less packages loaded (and auto-load the packages as used).
First, it is absolutely critical that the OS creates some log or structure of operations on the TRAM for filesystem operations. Basically, if the OS can mark the beginning and end of an operation and place it in this memory, you can now get a journaled meta data filesystem without a complete re-architecture of a filesystem.
Basically, if the OS can determine the beg/end of an operation (transaction) and it logs this information, then we have a journaling file system. Any persistent storage will suffice for the journal - 'TRAM' or hard disk or clay bricks. The only difference is the access time.
In general there is no magical way for the OS to know what data is the beg/end of a transaction. The OS could try to handle meta-data in this fashion. It can log the meta-data changes it would make in atomic transactions and replay un-commited transactions on a reboot. However, the file system still needs to be aware of this journaling.
Consider a power failure during a commit to the file system. The file system is in a partially modified state and the transaction has not been retired from the TRAM journal (since it did not complete). When the system boots again, the TRAM journal is replayed and the same operation begins again, except this time on an inconsistent file system. The file system needs to recognize that a partially commited transaction needs to be rolled back.
The above is based on my (very incomplete) understanding of journaling file systems. However, a TRAM card amounts to a cache for a file system journal, so in no sense is it going to replace or leap-frog journaling file systems.
Ender's Game (Card) Ringworld, Integral Trees, Smoke Ring (Niven) Snowcrash, Cryptonomicon (Stephenson) Foundation and Robot series, Nightfall, basically everything he ever wrote (Asimov) Starship Troopers, Methusela's Children, Stranger in a Strange Land, most of the stories, few of the books (Heinlen) Do Androids Dream of Electric Sheep, etc. (PK Dick) Red/Green/Blue Mars (Kim Stanley Robinson) Neuromancer, Burning Chrome (short stories) (Gibson) Watchmen (A. Moore, D. Gibbons) Dune (first only) (Hebert) Moving Mars, Anvil of Stars, Forge of God, Eternity, etc. (Greg Bear) Postman, Uplift series (Brin) Contact (Sagan) Battlefield Earth (Hubbard) Psion/Cat's Paw series (Vinge) Falkenberg books (Pournelle) Dorsai books (Gordon R. Dickinson) Stainless Steel Rat series (Harrison) 2001 series (AC Clarke) Hitchhiker's Guide (Adams) HG Wells Ray Bradbury
Internet purchases fall into two categories. Orders in which the Internet is used solely as a communication medium (exactly like telephone orders), and orders for information which can take place totally over the Internet. The first class is of no concern as they are exactly like telephone orders. The second category will probably be the most lucrative in the long run, but a tax of this kind could never be enforced.
Why? The entire transaction takes place on the Internet, so geo-political boundaries are irrelevant. I don't care if slashdot is hosted in the US or in Africa. All this will lead to is the migration of business to a less taxable domain.
Slashdot Mirror
I spent yesterday looking at eclipse CDT again. Basically the only feature I am interested in is 'content assist' - emacs rules it in every other way (for me). Unfortunately, that doesn't really work. I used the RPM available for Fedora 5 and it basically fails to index. Repeated problems failing to update project paths. After repeated failures trying to get CA to work, I tried to replicate the screen shot they show with 'mystruct' - that didn't work the first few times I tried it. Either something is badly wrong with the FC5 RPM or it isn't quite there yet. I'll check it out again in another year, but at the moment it still sucks for C/C++ Even if the 'content assist' feature worked, it still needs a good indent engine and to make better use of screen space. I wasn't able to see much code even when maximized - looked to be due to extra spacing between lines of code.
If only the CEDET package for emacs actually worked...
He also wrote the best Daredevil stories. He created Elektra (which will probably be another horrible movie) and IIRC Bullseye as well. Some of the Robocop movie scripts (which I could have left out) were written by him as well.
Network transparency can easily be provided by modern component object models like GNOME's Bonobo and KDE's Kparts, with the added bonus that clients are thin and so still usable over a high-latency network.
This is an amusing and rather bad idea.
Currently both GNOME and KDE achieve network transparency by virtue of using the X Window System. Also, there are a lot of X applications that don't use either of those object models: straight Qt/Gtk+, Tk, Xlib, Xt/Xaw/Motif, etc. There are too many for me to bother listing here. Even if the only apps that mattered were GNOME and KDE apps (most definitely not the case), this would be a really bad idea.
How exactly will Kparts and Bonobo achieve this magic feat anyway? I admit that I am not too familiar with either of these technologies. However, I believe they basically allow a program to use components which can be instantiated either in process (via shared libraries) or in another process (via remote procedure calls using RPC/CORBA or something similar). Nothing about them says network transparent graphics. How do I display a program running on a SPARC workstation on my x86 PC using these technologies? Or one running on an x86 PC running Linux or BSD and displaying on an x86 PC running MS Windows? Please enlighten me. I am sure Microsoft would be interested in doing it with OLE/COM/ActiveX/whatever as well.
I wouldn't go so far as to call XFree86 obsolete, but the technologies upon which it's based certainly are.
What part of them do you consider obsolete? I haven't heard of anything obsoleting client/server architectures. For that matter, the X11 protocol is really nothing more than an asynchronous remote procedure call (see CORBA/RPC). I wasn't aware that those were obsolete either.
While there are some problems with the X Window System, they won't be solved by a mass switch to Kparts/Bonobo.
IIRC, it came with a DOS extender that allowed the creation of programs with a flat 32 bit address space. This was very useful, as at the time programmers were still dealing with segments on x86 (limiting arrays to 64K, etc).
There are ways to create FTP 'filesystems' (OS/2 was doing it in 1994ish?) Failing that, you can easily write an external script and bind it to a macro in the editor.
That is exactly what emacs does. It uses a script (originally ange-ftp, not sure what it is now). It actually launches an ftp client and issues commands to it in response to your key presses.
People think that emacs is bloated, but that is a misconception. It is true that it is larger than vi, but the largest portion is due to preloaded scripts. An emacs binary contains a large amount of initialized data (generated from emacs after loading many packages). While it isn't worthwhile, you could build a smaller emacs with less packages loaded (and auto-load the packages as used).First, it is absolutely critical that the OS creates some log or structure of operations on the TRAM for filesystem operations. Basically, if the OS can mark the beginning and end of an operation and place it in this memory, you can now get a journaled meta data filesystem without a complete re-architecture of a filesystem.
Basically, if the OS can determine the beg/end of an operation (transaction) and it logs this information, then we have a journaling file system. Any persistent storage will suffice for the journal - 'TRAM' or hard disk or clay bricks. The only difference is the access time.
In general there is no magical way for the OS to know what data is the beg/end of a transaction. The OS could try to handle meta-data in this fashion. It can log the meta-data changes it would make in atomic transactions and replay un-commited transactions on a reboot. However, the file system still needs to be aware of this journaling.
Consider a power failure during a commit to the file system. The file system is in a partially modified state and the transaction has not been retired from the TRAM journal (since it did not complete). When the system boots again, the TRAM journal is replayed and the same operation begins again, except this time on an inconsistent file system. The file system needs to recognize that a partially commited transaction needs to be rolled back.
The above is based on my (very incomplete) understanding of journaling file systems. However, a TRAM card amounts to a cache for a file system journal, so in no sense is it going to replace or leap-frog journaling file systems.
In no particular order:
Ender's Game (Card)
Ringworld, Integral Trees, Smoke Ring (Niven)
Snowcrash, Cryptonomicon (Stephenson)
Foundation and Robot series, Nightfall, basically everything he ever wrote (Asimov)
Starship Troopers, Methusela's Children, Stranger in a Strange Land, most of the stories, few of the books (Heinlen)
Do Androids Dream of Electric Sheep, etc. (PK Dick)
Red/Green/Blue Mars (Kim Stanley Robinson)
Neuromancer, Burning Chrome (short stories) (Gibson)
Watchmen (A. Moore, D. Gibbons)
Dune (first only) (Hebert)
Moving Mars, Anvil of Stars, Forge of God, Eternity, etc. (Greg Bear)
Postman, Uplift series (Brin)
Contact (Sagan)
Battlefield Earth (Hubbard)
Psion/Cat's Paw series (Vinge)
Falkenberg books (Pournelle)
Dorsai books (Gordon R. Dickinson)
Stainless Steel Rat series (Harrison)
2001 series (AC Clarke)
Hitchhiker's Guide (Adams)
HG Wells
Ray Bradbury
Internet purchases fall into two categories. Orders in which the Internet is used solely as a communication medium (exactly like telephone orders), and orders for information which can take place totally over the Internet. The first class is of no concern as they are exactly like telephone orders. The second category will probably be the most lucrative in the long run, but a tax of this kind could never be enforced.
Why? The entire transaction takes place on the Internet, so geo-political boundaries are irrelevant. I don't care if slashdot is hosted in the US or in Africa. All this will lead to is the migration of business to a less taxable domain.