Even the seemingly chaotic and messy act of "drilling down" to a deeply nested file using the Spatial Finder, double-clicking one folder after another and spawning windows like crazy, can be accomplished with comparatively little conscious thought. The user finds his way using visual cues (reinforced by the coherency and stability of the Spatial Finder) rather than by rote memorization of file paths. In the same way that you might drive a familiar route without knowing all the street names or exit numbers, the Spatial Finder user might not know the actual path of the file on disk. But like the driver, the user does not need to know all the names of the places along the way. He only needs to know where he is, and how to get there from here. In a non-spatial system, users must remember "addresses." The Spatial Finder enables users to remember locations.
Now, there is a problem with spatial locations. Specifically, I can't remember the location of EVERY HOUSE AND BUILDING IN THE F*CKING CITY. Given that I have 100GB on line, in 60,000+ documents, and piles more on tape, I can't remember each file. What I do is give each of these and ADDRESS, just like my house has an ADDRESS. We have directories (on-line and off-line) that let us retrieve the location given the address. In other words, to manage larger pieces of data, people resort to EXACTELY the scheme that OSX uses (and most other modern GUIs). Also, addresses can be manipulated symbolically. If I know the library location of a book I am interested in (in the card catalog -- another fine example), I can look for other related material.Kind of demolishes the rest of the argument.
I do wonder if some people just can't reason symbolically. If so, there should be computer (and other) interfaces for them. As to light switches, etc., switches are ok, but if you are in a large building, -or- wish to automate, you need some form of symbolic addressing for the switches. A hierarchy then makes sense (assume lights/ac/sprinklers). And you're back to paths. So, people who CAN'T deal with the "path" interfaces should have the "direct" option, but its their own problem when trying to deal with complexity.
My server(s) do not run a GUI. In fact, they have NO monitor, NO keyboard, NO mouse. Even better, the kernel doesn't even have support for any of those things in it.
Now, one of the servers (used as an MP3 mplayer) uses a cheap m'board, which has "built-in" video. The file server also has a video board in it. I would take the video board OUT of the file server, because I don't need it... BUT the BIOS doesn't have the feature of redirecting over serial or IP. Normally, this wouldn't matter, expect if the CMOS gets munged (which has happened twice with the cheap MP3 m'board, and never with the file server). Both boxes can run GUI configuration tools, either via HTTP, or via X. Of course there never is a "local bitmap" to copy. Both of these boxes have far far better things to use memory and resources for. Like playing MP3s, or file serving.
Network transparency is a Good Thing (tm). You don't need local GUIs, and thus can get rid of monitors, keyboards, etc. for a lot of boxes. So, use it, exploit it. I really DON'T want to run a GUI on these boxes... that's not what they are for.
Now, I interpret you comment to be that the X server should provide more advanced visuals to clients. Can you give examples?
The main problem is that there is no free lunch. The laws of thermodynamics will bite your ass. If the code is bigger, it still has to be fetched from memory, and the processor still has to parse through it. If there is MORE code, then either (1) there is more power dissipation (heat), or a lower clock frequency. Instructions may be predicated (and are, in the ia64), but the damn code STILL needs to be fetched. A better idea would be to modify the run-time code (ala Java hotspot, or Transmeta code-morphing). The problem is made worse by the current crop of compilers: For example:
if (nasty_error)
{
do_some_error_recovery;
}
Most compilers have NO idea that the error recovery code is going to be rarely used, and should be moved out of line to avoid fetching.
The SUN C compiler does have a "#pragma rarely_used" which may be applicable, but is limited (I believe it works on functions only).
So, the problem with very wide RISC is code size, which gives us a heat problem.
HP/UX has (as far as I know) a PA-RISC to PA-RISC morpher that gets linked into applications. That seems like a reasonable solution to the clunky compilers. Of course, I want the option to have a very big address space, AND run-time optimization , AND the ability to give more semantic information to my compiler. Maybe next year...
The phone companies (among others) are granted what is known as a "natural monopoly". Basically, the right to string wires (or bury them, etc.). Go the the gov' and ask them for permission to do the same thing... you can't have it. And, because monopolies are (in general) a "bad thing", in that they can extend to other areas (eg. If the phone company where the ONLY company allowed to string cable, the cable companies would be, well, screwed). As long as we are NOT allowed to string the extra cable, and this is imposed by gov' fiat, the companies that HAVE the cable must be forced to "share the wealth".
And that's the argument for why "TELCO must share". As to "viable alternatives", what would you propose? The only viable alternative I can see is the TV cable company....choke... another "natural monopoly".
Ratboy.
Re:Is this the first signs of a turnaround?
on
Forget Moore's Law?
·
· Score: 1
"Software over twenty years has gotten bigger, not better".
Let's examine this, carefully...
(1) 20 years ago (1983), UNIX was solely under AT&T control. A commercial license would set you back a VERY hefty sum. People were VERY careful about AT&Ts trademark -- we refered to UNIX as UN*X...
(2) No MS Windows, no X. Indeed, SUN and Apollo were just beginning the workstation era.
(3) People used WordStar 3. Or WANG or MICOM (dedicated Word Processors). Most of these ran on 8 bit processors. IBM had released the DisplayWrite (based on the 8086). The PC was new.
(4) Hierarchical directories were still in the future for most. Even VMS (which did support directory trees) was clumsy at best. And UNIX was very far away for most.
(5) Even the UNIX system of the time didn't offer loadable drivers. Generally, if you wanted a new driver, you rebuilt the OS. PC DOS 2 (released just around then) was one of the first to offer this feature generally.
(6) ANSI C wasn't in use then. Forget C++. C compilers were available, without "void", function templates, and non-standard run-time libraries (Whitesmiths, which used different printf() strings, etc.).
(7) BASIC and Assembler were the common PC (micro) programming languages. And the BASIC was not typed, etc. as the modern variants are.
(8) Forget your 486 -- the 286 was JUST sampling, and only ran at 4-6Mhz.
(9) No shared libraries, processes, threads, windowing, mice.
If you don't think we have improved... then I sentence you to a MONTH of using nothing but 1983 (and older) software. You can run most of it with emulators...
You have just re-invented vi -- perhaps vim! Except that your approach takes more keystrokes, and isn't quite as fast.
Shift-space: The shift and space are NOT next to each other on most keyboards, but are on others. Also, the Shift space sequence tends to be a TWO hand operation (I've asked people to try it -- for righties, its left pinky shift, right thumb space -- if they were touch typists; there are other variants).
Now, the ESC key is nasty in vi -- generally, uppermost left key, but it also creeps on the keyboard. I have to think about mapping it somewhere else! Still -- LEAP in vi is:
/ return
with, of course, an added leading ESC if I were typing. Back leaps use ? instead of/.
Repeat the leap? / return. Repeat an editing operation? . return. Etc.
No menus, no GUI, no muss, no fuss.
Graft on your extensions into VI or EMACS please. [ps. I can't use EMACS - it makes my hands hurt. Really.]. Good old home row visual editing. Stick some smarts in there, and shoot for the stars.
But... this isn't new. Not even that interesting. I expected more, Jef.
11 Microsoft Windows family products. 4 Linux products. 1 OS/2 3 Netware 1 BSD 2 Mac OS/X 2 utility packages (removed)
2 Mac Windows compatibility
OS/2 is dead. Really. So we will eliminate that. Netware will be eliminated, it's appeal is not as an application base. Nor would anyone with only 1 to 3 PCs at home use Netware.
4 Unix-like OSs (Linux/BSD). The bulk of which are not actually designed to be a commercial OS (hey, I work on Linux because I like it, I have NEVER made money on it). What I find interesting in this data is that there are 2 Redhat and 2 Suse products (personal/professional) going head to head. More power to them. I guess Suse and Redhat compete with each other?
So, we have 2 Mac OSs, and 2 packages to allow those OSs to run MS Windows. Given that these are virtual PC products, they come with Windows (so I'll move them into the Windows category).
Giving 13 Windows products. Not too shabby.
Ok, I'll give you the benefit of the doubt. I assume that you are familiar with Linux, BSD, and Windows, and have made your choice. Windows is better, right? Why? (and the answer -- it runs MS Office cannot be used).
I like *that* spin. If Unix were 40, it would have been released in 1962. But, it makes a nice spin, after all, anything "40"ish is over the hill.
After all a 30 year old would be just prime now, right? And, a 34 year old is prime with a bit more experience, right? But 40, well, that's just too old.
When I am hacking systems, I DON'T WANT THE SOURCE. The source actually gets in the way. Simply because I am led down the path that the developer was on when writing the thing in the first place. And, the source MAY NOT be what is actually running. The object code is actually a better place to start.
What is "sftp"? SSH has "scp", and, yes, I agree that it is "bare-bones". So is the "cp" command.
Now, your customers need to send you files... Why not give them a tcl/tk/expect script that uses scp? If you want such a beast, email me, and we'll discuss it. Try "fred_weigel at h o t m a i l.com" Excuse the anti-spam filter.
Of course, FTP is vulnerable, simply because the data is typically not encrypted. I assume that is the main reason you don't want to use it (plus, passwords are snoopable). Ok for local use, but not for anything else. As long as "telnet" and "ftp" are actually used on the internet, hackers really don't need to do much work! Yes, you want SSH, SCP, or equivalents. The command line interfaces are just fine, but if your users need to use "hand-holding" software, there are ways to "gui it up".
Busses WILL always be interceptable. Otherwise, they are NOT USEABLE.
Also, any one to many encryption is vulnernable. Its the nature of the thing.
That's why there is a LAW about trying to circumvent these measures... If the measures would actually work, or the people who produced them actually had faith in them, there would be no reason to lobby for legal protection.
All I can do is keep "casual hackers" out, where the cost to break in is prohibitive compared to any rewards. And even there, hackers may not measure effort by money (I certainly don't).
Keep in mind the cell phone hacks that (first) replaced the home number, (second) generated random home numbers to provide for "untraceable" phone service (and, as a secondary benefit, free phone service). The cell phone manufacturer sure wasn't expecting the hacker to scrape down micro-chips and replace them. But that's what happened.
On to other matters -- MS is NOT a hardware vendor. Sure, they sell mice and keyboards, but they mostly sell software. MS doesn't want to produce a "secure" OS. At least, not one that is "secure" in any sane definition of that word. They DO want to produce an OS that will make it VERY difficult to produce copies, legitimate or not, of material produced by large companies. Not impossible, mind you, just difficult. It WON'T secure YOUR data. There seems to be no initiative for strong encryption on all email (and why not? there are public key servers. If MS put this into Outlook Express, all SPAM could be stopped by simply requiring all incoming emails to carry valid digital signatures. The email would have to be encrypted to MY public key, and every other recipients. It would be very expensive to generate SPAM -- in terms of CPU cycles.) and on documents stored. There is little need for a "hardware" solution to secure YOUR data, just needs software support. But Microsoft want to solve the "one to many" problem, which is guaranteed to be breakable, unless the cost point is set too high.
So.. what have we learned? Hacking/cracking won't be stopped. Your data will not be secure. It will be expensive to make copies, in whole or part of any large corporations data (they will have to purchase an encryption key). It is illegal (in the US) to attempt to circumvent that measure, because MS and the content vendors know that it CAN be broken.
It strikes me that SQL is a standard. Yes, the TRANSPORT of the SQL changes according to the database, but the SQL is, well... SQL.
So, that's the way I designed my database connector. Standardize the transport, and send SQL. Of course you keep the SQL you are using to the common base (what is it now, AFAIK SQL92, but I am not going to bother to look it up).
Otherwise, the use of SQL itself doesn't make sense. Look at an analogy: you are putting a scripting language into your application, and you choose an ANSI standard. Say (to be obscure), REXX. Now, different REXX vendors have different ways of linking in your scripts, so you loose faith. Instead of replacing REXX, you decide to write a Perl to REXX translator. Well... you go and BUY this thing from someone else. The claim is that this is a "universal" solution, because no matter HOW the REXX transport changes or someone modifies the ANSI standard language, you won't have to change your code. On the other hand, the translator itself is incomplete, and the vendor changes it 3 times a year forever (this actually happens, I have lost count on the number of times Microsoft has rolled out a new database connector!).
You should look at what SQL you intend on using, and check if the various vendors support that subset. Maybe ensure that you are using ANSI SQL. If the SQL database vendors AREN'T support ANSI SQL, take them to task! You shouldn't have to be buying additional software to make up a lack of support for the standard. And when this is true, the actual transport issue can be easily solved by your existing shim.
The next level in anti-spam measures is to actually IGNORE them. Use "active" countermeasures... I am working on a front-end for email that requires an active response to any unknown email. And, while the email is coming in, the server waits 9 minutes between lines. If the new email is longer than a cut-off, and the sender isn't known, it accepts the rest. The idea is to tie up a port on the spammer (or forwarder) for as long as feasible. Email return addresses are checked, and if not valid, immediately deleted. And, as a last precaution, if there are any http: tags in the email, the address is checked, and if its numeric, the email is discarded. End of story. From then on out I ignore the spammers. I just don't see any, AND (as another benefit), I automatically hurt the spammers (having the port tied up). Also, I have a little GUI gizmo that shows me when UCE is coming in, and records the SMTP IP address. Since my server is running very slowly, I can actually catch them "in the act", and, if desired, start hacking on their box. What fun!
What we need is software like this. (Don't ask, mine isn't ready for release, and I don't code "collaboratively" -- I do it for my own amusement).
FYI: X is designed to allow applications to dynamically change display settings, AND talk to more than one X server at once.
For changing "display settings", an application can use any visual available. Of course, common "PC" display hardware won't let you run direct color and color-map in separate windows at the same time -- that would be a hardware limitation though, and not a software limitation.
Of course an application can talk to multiple X servers. Not many do, but this is NOT a defect of the X protocol.
As to moving an application from one X server to another -- this requires a bit more work. It is "doable". I would use something like Xnest as a base. The local applications would connect to the local X server, that would keep track of the applications screens. The local X server would then connect with a remote X server (as a client), reproducing the applications resources on the remote X server. This would also allow X applications to be "suspended" -- in a state where they are NOT connected to any remote servers, and yet are still running, ready to be connected to.
The local X server could also do multiplexing, allowing multiple input streams, and muxing output to a collection of remote X servers. I wouldn't implement that feature in "version 1", though.
Maybe something like this already exists?
Anyway, its not an issue with the X protocol itself...
Problems: Change of visual in moving from one remote X server to another. Eg. color-map visual moving to a monochrome X-Terminal.
I have written this article before, and so I'm not going to repeat myself. Go see
Article (#3842766)
for the details on exactly why Palladium is REALLY, REALLY bad for your computer. As to it being a "security" thing, preventing "viruses"...
It can't. Palladium can only make computing more difficult.
Ratboy.
The advantage Kodak has (and its a big one), is that they can fund development of a proper digital projector. 1280x1024 doesn't cut it...
We need around 4 times that many pixels. That would come to ~4 million pixels, or ~12 million bytes per frame. At 30 fps, that's 360MB per second of projector delivered data.
And that's the bottom of the "acceptable" range. Now, here's the problem. Even a fiber channel disk only delivers 100MB per second. We are talking about at least 3 fiber channel interfaces. Output data would have to be multiple PCI busses or custom. How many companies can swing this kind of gear? Kodak is pursuing this. There are NOT "100s of companies". There aren't "100s" in the fiber channel (or other high-speed disc interconnect) business. There aren't "100s" of companies building that kind of display hardware either.
And, how many manufacturers build 'frames that are capable of 800MB+ SUSTAINED I/O (400MB in/400MB out)? Let me see... I think 4 (may be wrong, but that's a reasonable first guess).
Kodak is packaging this for theaters, and should make a killing on this. Film stock CANNOT be reused, and only a few labs can make duplicates.
I would think that a movie would be delivered on hard discs, in a RAID configuration. The digital data can be duplicated locally, and the theaters can rent the discs the same way they currently rent film. Kodak can REUSE the drives for the "next big blockbuster". The consumer gets a high resolution movie. Not yet there (DLP is, in my opinion, a waste of time), but its coming.
Of course, Kodak may mess this up, but it could be a massive thing. Kodak is already making the prints, and they can't be recycled. They just migrate into supplying high-resolution digital film carriers instead. And rent them out. Of course it helps if they control the projectors too.
The big problem I see is loading the digital projector. The van arrives, with the movie on hard disc. The operator has to insert the drives (or drive groups, more likely). This could take some time. May a few hours. Again, this is similar to film, seems a bit worse to me.
Why short Kodak? They have an imaging division that is working on *exactly* those issues. They have demonstrated a prototype digital projector as well.
Ratboy
Re:Counter argument because no one else will
on
MS Palladium Patent
·
· Score: 1
Except -- it CAN'T work that way... and the patent SPECIFICALLY states that it doesn't work that way... which means Juarez is lying.
Now, on to specifics -- either the ENTIRE base of Windows needs to be security 'vetted, which IS NOT HAPPENING, or untrusted programs are going to be kicked out whenever any DRM data is in memory.
The reason? Let us take the easiest thing that comes to mind -- You are running a screen saver, say, and you then run some DRM content. Attack point is the screen. Notice the Microsoft screen saver that distorts the screen image ala magnifying glass. Either it has direct access to screen data THAT DOESN'T BELONG TO IT, or ANOTHER REPRESENTATION OF THE DATA. The BEST thing is the first, the screen saver is manipulating screen data. Now, this is a MAJOR violation of MAC and DRM, *unless* the only screen savers allowed are "authorized" by your local friendly DRM people.
Does this scare you? It should. Major pieces of functionality will be INSTANTLY lost. None of your screen savers, blind readers, macro recorders, sound enhancers, custom drivers, etc. CAN BE ALLOWED TO KEEP THE RIGHTS OF A SINGLE DRM VENDOR.
And how will you be able to keep DRM content off of your computer? Any program you put on may easily have DRM content -- any Web site may have DRM content. And, thanks to the "ActiveX" model, may be able to SAVE that content to your system. Read MS's latest EULA -- download to your computer any time, and disable ANYTHING.
Welcome to the Palladium world.
Ratboy.
Just trying in inject a ray of gloom into your obviously cheery world.
Disney is using Linux? The little sh*ts! About the only good that Disney has done is the work on Squeak that they (probably) funded. The Disney attitude towards copyright extension s*cks dead wookie. Personally, I would like the GNU copyleft to DISCLUDE Disney specifically. Make them pay for OSs. At least until Mickey Mouse is public domain.
Ah well, its not going to happen. Just remember: the enemy of your enemy is NOT your friend.
Jeez - Disney, ultimate closed IP purveyor, supporter of the most draconian IP laws ever, and they get to benefit from Free Software. There just ain't no justice.
Ratboy.
PS. I haven't actually read the other comments yet, and this is probably a popular sentiment. Feel free to ding me if you must...
Well... there is a potential class action suite available for Macrovision.
Try this line: create a DVD, low volume production run, that enables Macrovision protection. Don't pay Macrovision the $0.05 per DVD. Advertise the DVD *and* the fact that it's copy protected with Macrovision (tm). Wait for Macrovision to sue. Now, claim that Macrovision hardware was supplied by the DVD manufacturer under license from Macrovision, and you just allowed the end user to turn on this standard feature. The end user certainly doesn't have a contract with Macrovision. Now, all DVDs that are Macrovision encoded have had $.05 added (or more) as Macrovision per media fees. Countersue with a restraint of trade (class action), to recoup that nickle from each media (Macrovision certainly made money, or should have, licensing hardware).
With that as a start, attack the VHS Macrovision market the same way (its probably easier to START with DVDs, because the Macrovision GENERATOR is everywhere).
I didn't make the laws. Government did. Should they be repealed? Maybe, maybe not. Will of the people.
Now, repeat: Ratboy is NOT a criminal. Microsoft IS a criminal. Ratboy does not have a criminal record. Ratboy is not a "pirate". Ratboy does not commit theft on ANY basis. Ratboy would have no problem SELLING software, or entering into contracts. (Ratboy does get background checks run on him). If Microsoft choose to SELL Ratboy the Windows system, Ratboy could resell it. Microsoft doesn't - all Windows users enter into a contract relationship with Microsoft. Who DOES have a criminal record.
Since you CAN'T BUY Microsoft software, but must LICENSE it, and a license is a contract between you and Microsoft, any use of Microsoft software is disallowed. A third party may supply the media, but the act of agreeing with the EULA to activate the software enters into a contract relationship with Microsoft. Answers your question -- there is NO partner or affiliate involved in making the contract with Microsoft. Because Microsoft doesn't want it. And, it was Microsofts idea to not sell the software, but to license it. So, governments that have laws such as this on the books SHOULD be stuck.
These are NOT DNS problems of any sort. And, DNS is a NAMING convention; it has nothing to do with politics or culture. Unless you think (for example) that computer source code should be 'vetted for politically and culturally correct variable names prior to publication... ".za" to ME (the user of the naming convention) simply means that the computer is likely in South Africa.
Of course, my computers naming ends in ".org" Which SHOULD mean to you that they aren't involved (primarily) in making money. And indeed I run a community bulletin. As to the political, social, or cultural bits -- the ".org" means about as much as ".za". A computer in South Africa could be under ".org". And, it would be easy to set up a computer PHYSICALLY in South Africa which has a ".us", ".ca", ".au", or ".de" (or whatever) domain.
A couple of facts for you...
1 - If anybody WANTS a TLD, they can set up their own root server. This alternative is available.
2 - The choice as to which root servers to use is up the to EACH DNS server operator. In a lot of cases, this is up to the individual 'net user. Many of us run "cacheing only" DNS servers.
3 - So, its happened already. Of course you CAN use the DNS server your ISP provides. However NOTHING prevents you from running your own.
4 - Even if you DON'T run your own DNS server, you can still easily use alternate TLDs. I believe that most MS Windows (tm) users fall into this category. Just add a new DNS server into your connection properties (or whatever its called) field.
5 - If you want a domain RELATIONSHIP, then you typically work within the "confines" of an organization that 'net users trust to provide top level DNS service. I find that ICANN does a reasonable job for my needs, and has a good relationship with 'net people (most sites are accessible); this makes using the "standard" root servers sufficient for my needs.
6 - Why the fsck would a large company or country want to opt out? I (as a user) may wish to blackhole the company, but the other way? Makes no sense to me. I could see a company wanting private root servers for Intranet applications, but not for Internet. And, for Intranet, why not use NIS (or something else) instead?
Slashdot Mirror
To quote from the article:
Even the seemingly chaotic and messy act of "drilling down" to a deeply nested file using the Spatial Finder, double-clicking one folder after another and spawning windows like crazy, can be accomplished with comparatively little conscious thought. The user finds his way using visual cues (reinforced by the coherency and stability of the Spatial Finder) rather than by rote memorization of file paths. In the same way that you might drive a familiar route without knowing all the street names or exit numbers, the Spatial Finder user might not know the actual path of the file on disk. But like the driver, the user does not need to know all the names of the places along the way. He only needs to know where he is, and how to get there from here. In a non-spatial system, users must remember "addresses." The Spatial Finder enables users to remember locations.
Now, there is a problem with spatial locations. Specifically, I can't remember the location of EVERY HOUSE AND BUILDING IN THE F*CKING CITY. Given that I have 100GB on line, in 60,000+ documents, and piles more on tape, I can't remember each file. What I do is give each of these and ADDRESS, just like my house has an ADDRESS. We have directories (on-line and off-line) that let us retrieve the location given the address. In other words, to manage larger pieces of data, people resort to EXACTELY the scheme that OSX uses (and most other modern GUIs). Also, addresses can be manipulated symbolically. If I know the library location of a book I am interested in (in the card catalog -- another fine example), I can look for other related material.Kind of demolishes the rest of the argument.
I do wonder if some people just can't reason symbolically. If so, there should be computer (and other) interfaces for them. As to light switches, etc., switches are ok, but if you are in a large building, -or- wish to automate, you need some form of symbolic addressing for the switches. A hierarchy then makes sense (assume lights/ac/sprinklers). And you're back to paths.
So, people who CAN'T deal with the "path" interfaces should have the "direct" option, but its their own problem when trying to deal with complexity.
Ratboy
My server(s) do not run a GUI. In fact, they have NO monitor, NO keyboard, NO mouse. Even better, the kernel doesn't even have support for any of those things in it.
Now, one of the servers (used as an MP3 mplayer) uses a cheap m'board, which has "built-in" video. The file server also has a video board in it. I would take the video board OUT of the file server, because I don't need it... BUT the BIOS doesn't have the feature of redirecting over serial or IP. Normally, this wouldn't matter, expect if the CMOS gets munged (which has happened twice with the cheap MP3 m'board, and never with the file server). Both boxes can run GUI configuration tools, either via HTTP, or via X. Of course there never is a "local bitmap" to copy. Both of these boxes have far far better things to use memory and resources for. Like playing MP3s, or file serving.
Network transparency is a Good Thing (tm). You don't need local GUIs, and thus can get rid of monitors, keyboards, etc. for a lot of boxes. So, use it, exploit it. I really DON'T want to run a GUI on these boxes... that's not what they are for.
Now, I interpret you comment to be that the X server should provide more advanced visuals to clients. Can you give examples?
Ratboy
The main problem is that there is no free lunch. The laws of thermodynamics will bite your ass. If the code is bigger, it still has to be fetched from memory, and the processor still has to parse through it. If there is MORE code, then either (1) there is more power dissipation (heat), or a lower clock frequency. Instructions may be predicated (and are, in the ia64), but the damn code STILL needs to be fetched. A better idea would be to modify the run-time code (ala Java hotspot, or Transmeta code-morphing). The problem is made worse by the current crop of compilers: For example:
if (nasty_error)
{
do_some_error_recovery;
}
Most compilers have NO idea that the error recovery code is going to be rarely used, and should be moved out of line to avoid fetching.
The SUN C compiler does have a "#pragma rarely_used" which may be applicable, but is limited (I believe it works on functions only).
So, the problem with very wide RISC is code size, which gives us a heat problem.
HP/UX has (as far as I know) a PA-RISC to PA-RISC morpher that gets linked into applications. That seems like a reasonable solution to the clunky compilers. Of course, I want the option to have a very big address space, AND run-time optimization , AND the ability to give more semantic information to my compiler. Maybe next year...
Ratboy.
The phone companies (among others) are granted what is known as a "natural monopoly". Basically, the right to string wires (or bury them, etc.). Go the the gov' and ask them for permission to do the same thing... you can't have it. And, because monopolies are (in general) a "bad thing", in that they can extend to other areas (eg. If the phone company where the ONLY company allowed to string cable, the cable companies would be, well, screwed). As long as we are NOT allowed to string the extra cable, and this is imposed by gov' fiat, the companies that HAVE the cable must be forced to "share the wealth".
...choke... another "natural monopoly".
And that's the argument for why "TELCO must share". As to "viable alternatives", what would you propose? The only viable alternative I can see is the TV cable company.
Ratboy.
"Software over twenty years has gotten bigger, not better".
Let's examine this, carefully...
(1) 20 years ago (1983), UNIX was solely under AT&T control. A commercial license would set you back a VERY hefty sum. People were VERY careful about AT&Ts trademark -- we refered to UNIX as UN*X...
(2) No MS Windows, no X. Indeed, SUN and Apollo were just beginning the workstation era.
(3) People used WordStar 3. Or WANG or MICOM (dedicated Word Processors). Most of these ran on 8 bit processors. IBM had released the DisplayWrite (based on the 8086). The PC was new.
(4) Hierarchical directories were still in the future for most. Even VMS (which did support directory trees) was clumsy at best. And UNIX was very far away for most.
(5) Even the UNIX system of the time didn't offer loadable drivers. Generally, if you wanted a new driver, you rebuilt the OS. PC DOS 2 (released just around then) was one of the first to offer this feature generally.
(6) ANSI C wasn't in use then. Forget C++. C compilers were available, without "void", function templates, and non-standard run-time libraries (Whitesmiths, which used different printf() strings, etc.).
(7) BASIC and Assembler were the common PC (micro) programming languages. And the BASIC was not typed, etc. as the modern variants are.
(8) Forget your 486 -- the 286 was JUST sampling, and only ran at 4-6Mhz.
(9) No shared libraries, processes, threads, windowing, mice.
If you don't think we have improved... then I sentence you to a MONTH of using nothing but 1983 (and older) software. You can run most of it with emulators...
Ratboy
Dear Jef:
/.
You have just re-invented vi -- perhaps vim! Except that your approach takes more keystrokes, and isn't quite as fast.
Shift-space: The shift and space are NOT next to each other on most keyboards, but are on others. Also, the Shift space sequence tends to be a TWO hand operation (I've asked people to try it -- for righties, its left pinky shift, right thumb space -- if they were touch typists; there are other variants).
Now, the ESC key is nasty in vi -- generally, uppermost left key, but it also creeps on the keyboard. I have to think about mapping it somewhere else! Still -- LEAP in vi is:
/ return
with, of course, an added leading ESC if I were typing. Back leaps use ? instead of
Repeat the leap? / return. Repeat an editing operation? . return. Etc.
No menus, no GUI, no muss, no fuss.
Graft on your extensions into VI or EMACS please. [ps. I can't use EMACS - it makes my hands hurt. Really.]. Good old home row visual editing. Stick some smarts in there, and shoot for the stars.
But... this isn't new. Not even that interesting. I expected more, Jef.
Ratboy
In that case, there seem to be two possible approaches, depending on how much formatting is to be retained:
1 - Print to Postscript from MS Word, and use Ghostscript to convert the PS pages into TIFF files for imaging and archival.
2 - Print to Text Only from MS Word, and send the resulting text files for imaging and archival.
I would go with (1), simply because it takes less skilled review of the work (simple match/no match, instead of "how close is it").
Ratboy
Lets have a look at your OS data:
11 Microsoft Windows family products.
4 Linux products.
1 OS/2
3 Netware
1 BSD
2 Mac OS/X
2 utility packages (removed)
2 Mac Windows compatibility
OS/2 is dead. Really. So we will eliminate that.
Netware will be eliminated, it's appeal is not as an application base. Nor would anyone with only 1 to 3 PCs at home use Netware.
4 Unix-like OSs (Linux/BSD). The bulk of which are not actually designed to be a commercial OS (hey, I work on Linux because I like it, I have NEVER made money on it). What I find interesting in this data is that there are 2 Redhat and 2 Suse products (personal/professional) going head to head. More power to them. I guess Suse and Redhat compete with each other?
So, we have 2 Mac OSs, and 2 packages to allow those OSs to run MS Windows. Given that these are virtual PC products, they come with Windows (so I'll move them into the Windows category).
Giving 13 Windows products. Not too shabby.
Ok, I'll give you the benefit of the doubt. I assume that you are familiar with Linux, BSD, and Windows, and have made your choice. Windows is better, right? Why? (and the answer -- it runs MS Office cannot be used).
Ratboy.
I like *that* spin. If Unix were 40, it would have been released in 1962. But, it makes a nice spin, after all, anything "40"ish is over the hill.
After all a 30 year old would be just prime now, right? And, a 34 year old is prime with a bit more experience, right? But 40, well, that's just too old.
Ratboy
When I am hacking systems, I DON'T WANT THE SOURCE. The source actually gets in the way. Simply because I am led down the path that the developer was on when writing the thing in the first place. And, the source MAY NOT be what is actually running. The object code is actually a better place to start.
What is "sftp"? SSH has "scp", and, yes, I
agree that it is "bare-bones". So is the
"cp" command.
Now, your customers need to send you files...
Why not give them a tcl/tk/expect script that
uses scp? If you want such a beast, email
me, and we'll discuss it. Try "fred_weigel at h o t m a i l.com" Excuse the anti-spam filter.
Of course, FTP is vulnerable, simply because the data is typically not encrypted. I assume that is the main reason you don't want to use it (plus, passwords are snoopable). Ok for local use, but not for anything else. As long as "telnet" and "ftp" are actually used on the internet, hackers really don't need to do much work! Yes, you want SSH, SCP, or equivalents. The command line interfaces are just fine, but if your users need to use "hand-holding" software, there are ways to "gui it up".
Ratboy
Busses WILL always be interceptable. Otherwise, they are NOT USEABLE.
Also, any one to many encryption is vulnernable. Its the nature of the thing.
That's why there is a LAW about trying to circumvent these measures... If the measures would actually work, or the people who produced them actually had faith in them, there would be no reason to lobby for legal protection.
All I can do is keep "casual hackers" out, where the cost to break in is prohibitive compared to any rewards. And even there, hackers may not measure effort by money (I certainly don't).
Keep in mind the cell phone hacks that (first) replaced the home number, (second) generated random home numbers to provide for "untraceable" phone service (and, as a secondary benefit, free phone service). The cell phone manufacturer sure wasn't expecting the hacker to scrape down micro-chips and replace them. But that's what happened.
On to other matters -- MS is NOT a hardware vendor. Sure, they sell mice and keyboards, but they mostly sell software. MS doesn't want to produce a "secure" OS. At least, not one that is "secure" in any sane definition of that word. They DO want to produce an OS that will make it VERY difficult to produce copies, legitimate or not, of material produced by large companies. Not impossible, mind you, just difficult. It WON'T secure YOUR data. There seems to be no initiative for strong encryption on all email (and why not? there are public key servers. If MS put this into Outlook Express, all SPAM could be stopped by simply requiring all incoming emails to carry valid digital signatures. The email would have to be encrypted to MY public key, and every other recipients. It would be very expensive to generate SPAM -- in terms of CPU cycles.) and on documents stored. There is little need for a "hardware" solution to secure YOUR data, just needs software support. But Microsoft want to solve the "one to many" problem, which is guaranteed to be breakable, unless the cost point is set too high.
So.. what have we learned? Hacking/cracking won't be stopped. Your data will not be secure. It will be expensive to make copies, in whole or part of any large corporations data (they will have to purchase an encryption key). It is illegal (in the US) to attempt to circumvent that measure, because MS and the content vendors know that it CAN be broken.
Ratboy.
It strikes me that SQL is a standard. Yes, the TRANSPORT of the SQL changes according to the database, but the SQL is, well... SQL.
So, that's the way I designed my database connector. Standardize the transport, and send SQL. Of course you keep the SQL you are using to the common base (what is it now, AFAIK SQL92, but I am not going to bother to look it up).
Otherwise, the use of SQL itself doesn't make sense. Look at an analogy: you are putting a scripting language into your application, and you choose an ANSI standard. Say (to be obscure), REXX. Now, different REXX vendors have different ways of linking in your scripts, so you loose faith. Instead of replacing REXX, you decide to write a Perl to REXX translator. Well... you go and BUY this thing from someone else. The claim is that this is a "universal" solution, because no matter HOW the REXX transport changes or someone modifies the ANSI standard language, you won't have to change your code. On the other hand, the translator itself is incomplete, and the vendor changes it 3 times a year forever (this actually happens, I have lost count on the number of times Microsoft has rolled out a new database connector!).
You should look at what SQL you intend on using, and check if the various vendors support that subset. Maybe ensure that you are using ANSI SQL. If the SQL database vendors AREN'T support ANSI SQL, take them to task! You shouldn't have to be buying additional software to make up a lack of support for the standard. And when this is true, the actual transport issue can be easily solved by your existing shim.
Ratboy.
The next level in anti-spam measures is to actually IGNORE them. Use "active" countermeasures... I am working on a front-end for email that requires an active response to any unknown email. And, while the email is coming in, the server waits 9 minutes between lines. If the new email is longer than a cut-off, and the sender isn't known, it accepts the rest. The idea is to tie up a port on the spammer (or forwarder) for as long as feasible. Email return addresses are checked, and if not valid, immediately deleted. And, as a last precaution, if there are any http: tags in the email, the address is checked, and if its numeric, the email is discarded. End of story. From then on out I ignore the spammers. I just don't see any, AND (as another benefit), I automatically hurt the spammers (having the port tied up). Also, I have a little GUI gizmo that shows me when UCE is coming in, and records the SMTP IP address. Since my server is running very slowly, I can actually catch them "in the act", and, if desired, start hacking on their box. What fun!
What we need is software like this. (Don't ask, mine isn't ready for release, and I don't code "collaboratively" -- I do it for my own amusement).
Ratboy.
FYI: X is designed to allow applications to dynamically change display settings, AND talk to more than one X server at once.
For changing "display settings", an application can use any visual available. Of course, common "PC" display hardware won't let you run direct color and color-map in separate windows at the same time -- that would be a hardware limitation though, and not a software limitation.
Of course an application can talk to multiple X servers. Not many do, but this is NOT a defect of the X protocol.
As to moving an application from one X server to another -- this requires a bit more work. It is "doable". I would use something like Xnest as a base. The local applications would connect to the local X server, that would keep track of the applications screens. The local X server would then connect with a remote X server (as a client), reproducing the applications resources on the remote X server. This would also allow X applications to be "suspended" -- in a state where they are NOT connected to any remote servers, and yet are still running, ready to be connected to.
The local X server could also do multiplexing, allowing multiple input streams, and muxing output to a collection of remote X servers. I wouldn't implement that feature in "version 1", though.
Maybe something like this already exists?
Anyway, its not an issue with the X protocol itself...
Problems: Change of visual in moving from one remote X server to another. Eg. color-map visual moving to a monochrome X-Terminal.
Ratboy
I have written this article before, and so I'm not going to repeat myself. Go see Article (#3842766) for the details on exactly why Palladium is REALLY, REALLY bad for your computer. As to it being a "security" thing, preventing "viruses"... It can't. Palladium can only make computing more difficult. Ratboy.
The advantage Kodak has (and its a big one), is that they can fund development of a proper digital projector. 1280x1024 doesn't cut it...
We need around 4 times that many pixels. That would come to ~4 million pixels, or ~12 million bytes per frame. At 30 fps, that's 360MB per second of projector delivered data.
And that's the bottom of the "acceptable" range. Now, here's the problem. Even a fiber channel disk only delivers 100MB per second. We are talking about at least 3 fiber channel interfaces. Output data would have to be multiple PCI busses or custom. How many companies can swing this kind of gear? Kodak is pursuing this. There are NOT "100s of companies". There aren't "100s" in the fiber channel (or other high-speed disc interconnect) business. There aren't "100s" of companies building that kind of display hardware either.
And, how many manufacturers build 'frames that are capable of 800MB+ SUSTAINED I/O (400MB in/400MB out)? Let me see... I think 4 (may be wrong, but that's a reasonable first guess).
Kodak is packaging this for theaters, and should make a killing on this. Film stock CANNOT be reused, and only a few labs can make duplicates.
I would think that a movie would be delivered on hard discs, in a RAID configuration. The digital data can be duplicated locally, and the theaters can rent the discs the same way they currently rent film. Kodak can REUSE the drives for the "next big blockbuster". The consumer gets a high resolution movie. Not yet there (DLP is, in my opinion, a waste of time), but its coming.
Of course, Kodak may mess this up, but it could be a massive thing. Kodak is already making the prints, and they can't be recycled. They just migrate into supplying high-resolution digital film carriers instead. And rent them out. Of course it helps if they control the projectors too.
The big problem I see is loading the digital projector. The van arrives, with the movie on hard disc. The operator has to insert the drives (or drive groups, more likely). This could take some time. May a few hours. Again, this is similar to film, seems a bit worse to me.
Ratboy
Why short Kodak? They have an imaging division
that is working on *exactly* those issues.
They have demonstrated a prototype digital
projector as well.
Ratboy
Except -- it CAN'T work that way... and the patent SPECIFICALLY states that it doesn't work that way... which means Juarez is lying.
Now, on to specifics -- either the ENTIRE base of Windows needs to be security 'vetted, which IS NOT HAPPENING, or untrusted programs are going to be kicked out whenever any DRM data is in memory.
The reason? Let us take the easiest thing that comes to mind -- You are running a screen saver, say, and you then run some DRM content. Attack point is the screen. Notice the Microsoft screen saver that distorts the screen image ala magnifying glass. Either it has direct access to screen data THAT DOESN'T BELONG TO IT, or ANOTHER REPRESENTATION OF THE DATA. The BEST thing is the first, the screen saver is manipulating screen data. Now, this is a MAJOR violation of MAC and DRM, *unless* the only screen savers allowed are "authorized" by your local friendly DRM people.
Does this scare you? It should. Major pieces of functionality will be INSTANTLY lost. None of your screen savers, blind readers, macro recorders, sound enhancers, custom drivers, etc. CAN BE ALLOWED TO KEEP THE RIGHTS OF A SINGLE DRM VENDOR.
And how will you be able to keep DRM content off of your computer? Any program you put on may easily have DRM content -- any Web site may have DRM content. And, thanks to the "ActiveX" model, may be able to SAVE that content to your system. Read MS's latest EULA -- download to your computer any time, and disable ANYTHING.
Welcome to the Palladium world.
Ratboy.
Just trying in inject a ray of gloom into your obviously cheery world.
Disney is using Linux? The little sh*ts! About the only good that Disney has done is the work on Squeak that they (probably) funded. The Disney attitude towards copyright extension s*cks dead wookie. Personally, I would like the GNU copyleft to DISCLUDE Disney specifically. Make them pay for OSs. At least until Mickey Mouse is public domain.
Ah well, its not going to happen. Just remember: the enemy of your enemy is NOT your friend.
Jeez - Disney, ultimate closed IP purveyor, supporter of the most draconian IP laws ever, and they get to benefit from Free Software. There just ain't no justice.
Ratboy.
PS. I haven't actually read the other comments yet, and this is probably a popular sentiment. Feel free to ding me if you must...
Of course Macrovision would sue. That's the point.
Well... there is a potential class action
suite available for Macrovision.
Try this line: create a DVD, low volume production run, that enables Macrovision protection. Don't pay Macrovision the $0.05 per DVD. Advertise the DVD *and* the fact that it's copy protected with Macrovision (tm). Wait for Macrovision to sue. Now, claim that Macrovision hardware was supplied by the DVD manufacturer under license from Macrovision, and you just allowed the end user to turn on this standard feature. The end user certainly doesn't have a contract with Macrovision. Now, all DVDs that are Macrovision encoded have had $.05 added (or more) as Macrovision per media fees. Countersue with a restraint of trade (class action), to recoup that nickle from each media (Macrovision certainly made money, or should have, licensing hardware).
With that as a start, attack the VHS Macrovision market the same way (its probably easier to START with DVDs, because the Macrovision GENERATOR is everywhere).
Ratboy.
Vlade- I am not a criminal. Microsoft is.
I didn't make the laws. Government did. Should they be repealed? Maybe, maybe not. Will of the people.
Now, repeat: Ratboy is NOT a criminal. Microsoft IS a criminal. Ratboy does not have a criminal record. Ratboy is not a "pirate". Ratboy does not commit theft on ANY basis. Ratboy would have no problem SELLING software, or entering into contracts. (Ratboy does get background checks run on him). If Microsoft choose to SELL Ratboy the Windows system, Ratboy could resell it. Microsoft doesn't - all Windows users enter into a contract relationship with Microsoft. Who DOES have a criminal record.
Ratboy.
Since you CAN'T BUY Microsoft software, but must LICENSE it, and a license is a contract between you and Microsoft, any use of Microsoft software is disallowed. A third party may supply the media, but the act of agreeing with the EULA to activate the software enters into a contract relationship with Microsoft. Answers your question -- there is NO partner or affiliate involved in making the contract with Microsoft. Because Microsoft doesn't want it. And, it was Microsofts idea to not sell the software, but to license it. So, governments that have laws such as this on the books SHOULD be stuck.
Ratboy.
These are NOT DNS problems of any sort. And, DNS is a NAMING convention; it has nothing to do with politics or culture. Unless you think (for example) that computer source code should be 'vetted for politically and culturally correct variable names prior to publication...
".za" to ME (the user of the naming convention) simply means that the computer is likely in South Africa.
Of course, my computers naming ends in ".org"
Which SHOULD mean to you that they aren't involved (primarily) in making money. And indeed I run a community bulletin. As to the political, social, or cultural bits -- the ".org" means about as much as ".za". A computer in South Africa could be under ".org". And, it would be easy to set up a computer PHYSICALLY in South Africa which has a ".us", ".ca", ".au", or ".de" (or whatever) domain.
A couple of facts for you...
1 - If anybody WANTS a TLD, they can set up their own root server. This alternative is available.
2 - The choice as to which root servers to use is up the to EACH DNS server operator. In a lot of cases, this is up to the individual 'net user. Many of us run "cacheing only" DNS servers.
3 - So, its happened already. Of course you CAN use the DNS server your ISP provides. However NOTHING prevents you from running your own.
4 - Even if you DON'T run your own DNS server, you can still easily use alternate TLDs. I believe that most MS Windows (tm) users fall into this category. Just add a new DNS server into your connection properties (or whatever its called) field.
5 - If you want a domain RELATIONSHIP, then you typically work within the "confines" of an organization that 'net users trust to provide top level DNS service. I find that ICANN does a reasonable job for my needs, and has a good relationship with 'net people (most sites are accessible); this makes using the "standard" root servers sufficient for my needs.
6 - Why the fsck would a large company or country want to opt out? I (as a user) may wish to blackhole the company, but the other way? Makes no sense to me. I could see a company wanting private root servers for Intranet applications, but not for Internet. And, for Intranet, why not use NIS (or something else) instead?
Ratboy.