OS manages system resources
on
Is UNIX An OS?
·
· Score: 1
I remember being taught in school that the role of an operating system consists of managing system resources (which is, perhaps, why they call it an "operating system" and not an "operating environment"). Providing a GUI to the user does not consist of managing system resources. Managing memory, persistent storage, I/O, and the like--that is what an operating system does.
A GUI, like the Windows GUI, the Mac GUI, KDE, Gnome, or whatever, is simply an interface to the operating system. As a result, I can have a POSIX-complient interface to the OS in Windows--and bypass the Windows GUI altogether (ok, not completely--the posix "window" resides inside the Windows GUI).
Any other definition seems to me to be remaking history. To my knowledge, this has been the definition of an operating system since the creation of the term operating system. Of course, I'm relying upon second hand information here--I wasn't around back in the 50s and 60s to personally observe the entymology of "operating system" develop.
I've been using Dell's XGA+ monitor (1400x1050 resolution). It's absolutely stunning, and does not cause any strain on my admitably young eyes (I'm 29).
I am a screen real estate hog. Back in 1995, I bought my first laptop--an NEC w/ a 12.1" XGA monitor (1024x768)--so that I could write Unix programs on the go (it ran Linux flawlessly) without forking out for a Tadpole (~$20,000 at the time). The XGA+ monitor causes less strain on my eyes than the old NEC. Furthermore, I suspect you can increase the resolution to 1600x1200 without causing eye strain. However, your mileage may vary.
This, of course, is why I stated in my earlier post, "you can tell them to garbage collect on demand".
My point is that you have little control over when the garbage collector interrupts your program and garbage collects. As a result, you will want to keep this to a minimum. To keep it at a minimum, don't do things that require garbage collection (spuriously allocating objects).
GCJ often produces code that runs slower than Java code inside a decent JIT. I have rarely seen instances where GCJ is useful for anything but server-side code, and its limits with respect to dynamic class loading often make its performance worse than that of a good JIT.
The choice of the VM can have a tremendous impact on the speed of code. For instance, Sun's HotSpot VM still sucks for client side code. For server-side code, HotSpot (and its garbage collector) can improve apparent performance considerably.
This poster is right on. I've been developing Java libraries for a living for a number of years (ok, only 3+ years). These recommendations summarize things wonderfully. I couldn't have said it better myself.
One thing I would like to emphasize. Try to keep memory allocation to a minimum. Besides the obvious performance hit for allocating the memory and initializing the variables, you also run into issues with garbage collection. You really don't have too much control over garbage collection, either. I've seen one Java program in particular that would take seemingly random 30-second+ pauses on the MS JVM included with IE. It turned out that the only problem was that the garbage collector was running during these pauses. Garbage collection schemes are left up to the implementation of the JVM. Since you have little control over them (you can tell them to garbage collect on demand, at least), it is best to avoid turning control over to them unless absolutely necessary. Doing simple object pooling can enhance the performance of a program tremendously. For all you library developers out there, that means *don't* create immutable classes. Immutable classes prevent the use of object pooling.
In fact, color TFT does fine in plain sunlight, so long as you remove the backlight & backing (so that the LCD panel is transparent, when turned off).
If I recall correctly, these old grayscale screens didn't have backlights (similar to a digital watch). The backlight is never as strong as direct sunlight, and thus a laptop that requires the backlight cannot be seen in plain daylight.
It seems like some entrepreneur would make a laptop with a removable backlight and back. I seem to remember one company doing such a thing about 8 years ago so that the laptop could be used with an overhead transparency machine. It never sold very well, though.
I'm not so sure this post should have been moderated down. I think this poster made a valid point (that GNOME monkeys have better things to do with their time). It was a witty response to a rather stupid point, IMHO.
Oh well. Slashdot seems to be continuing its downward slope. . Remember the days when "http://www.slashdot.org" didn't work? You had to use "http://slashdot.org".
Here in the US, natural gas makes sense. We've got loads of supplies (we're the Saudi Arabia of the natural gas world). It's cheap. It's very clean burning. Why don't we use it? No infrastructure.
A modest proposal: convert all civic vehicles to natural gas. This is already being done in many cities. However, we also need to require the motor pools for these cities to remove their filling stations. Make the civic vehicles fill up their cars at ordinary gas stations. As such, you will create a demand for gas stations that carry natural gas. Then, the early adopters can switch their vehicles to natural gas. Finally, Detroit will start making natural gas cars.
Once that happens, people will buy them. Even though there's a slight increase in danger with natural gas (estimates range from 30 to 150 additional deaths per year due to explosions from natural gas tanks), natural gas is cheaper and cleaner. The US can nationalize its fossil fuel consumption, removing our dependence on foreign oil. We could then tax the shit out of old gasoline (petrol for you non-US folk), using the tax revenues to invest into alternative fuel research.
Problems? Natural gas is very difficult to transport. Pipelines can't move gas--you have to liquify the stuff by putting it under immense pressure. That will cost the oil companies a lot of money. However, they should be happy to return energy production to the US. US is considered a low risk area for energy production--there's little risk the US government will be overthrown, with the new government nationalizing assets. Seems to me that the trade off would be very appealing for many companies.
I went to see the director's cut in the theater the same day I saw the original on TV. I thus had a good comparison with which to see what was added and deleted. As soon as the director's cut had ended, it was obvious. Why the hell would Deckard have dreamed about the unicorn, and his boss have left an origami unicorn behind, unless Deckard was himself a replicant? I mean, isn't it obvious?
I remember telling this to many people at the time. No one believed me. Alas, now I am vindicated.
Really, not that much changed between the director's cut and the regular. That dream sequence with the unicorn kind of stuck out, too. They kind of hit you over the head when they say something about being able to control replicants' dreams.
What I think is so amazing is how the entire film's meaning can change with a delta of about 30 seconds of video (forget the overdubbing...that was merely done to satisfy the Hollywood types). Kind of amazing. The film is 1000% better with the director's cut, as well.
At any rate, I'm glad that my hypothesis was correct. However, I'm kind of sad they had to make it definitive, though. One of the great things about art is that it can be interpreted in so many ways...
I have pondered this question quite seriously. I'm heading to Aberdeen, Scotland, in a few months. Here's the long and the short of it.
The main places you're seeing venture capital, and thus a thriving cutting edge tech schene, is Ireland (Dublin, I think..Ireland was out of the question for me for other reasons) & London. Both of these have a great high tech scene, with programmers making good money. DSL is being offered in both these places (think about it...no broadband, no high tech...). DSL is even available in parts of Aberdeen (this tipped the scales for me, as it's a better location for my spouse).
If you're using some of the latest technologies (JSPs, EJBs, CORBA, DCOM) and have some experience, you wages may even exceed those typical in the US. If you do training, you'll make significantly more (they're a little behind the US in terms of adoption of bleeding edge tech, so the demand for trainers is higher).
If you're a rank-and-file programmer, I think you'll easily find work making, by local standards, a lot of money. At this level, US counterparts make significantly more. That said, the recent startup scene in London and Ireland is supposedly hot enough that companies are beginning to offer stock options. I think this will get more common as the high tech labor force is further tightened. The European stock markets have done pretty well in the past few years, and the conditions seem to me to be similar to the US in the mid to late '80s (individual stock ownership, volume, etc...).
I don't think you'll beat the business climate in the Bay area, or Seattle, or Washington, DC. You might not beat it in any of the next six or seven cities in the US. That said, it's all good. You could probably choose some place like Tangiers and do fine in the high tech biz.
I think the idea was to build the encryption scheme first. I began a search for a suitable algorithm about 4 years ago. To date, the only algorithms I found that were suitable required floating point math. I didn't have the collective mind of slashdot behind me then. Now I do. So, if you have a *suggestion*, please let me know if you are aware of any integer fractal/chaos algorithms. No more, no less. I'm not trying to claim that I have some kick ass encryption scheme. I have an idea. I'd like to further the idea to a prototype. Until then, I still search.
Once done, I will turn over my work to the world. I don't want to hoard it. I merely want strong encryption that is fast enough to handle video streams. I also want it to be far more secure than any of the conventional 2-way hashing algorithms. Even the most robust of the 2-way hashing algorithms can be defeated with a finite amount of computing power. Use a key that approaches infinite lenght and you get a far more secure algorithm. This is the idea behind 3-des (as opposed to des, at least). Increased key length == more security. That said, a properly chosen fractal algorithm should approach randomness (or, at least, it should come close to being non-predictable). The randomness should allow for a key length that is more secure. The fractal part should help take care of the non-repeating part (that is, the predictability part). If it's a one-time pad, then all the better. The causal part of the fractal algorithm should allow both encryption and decryption, as both sides can generate the key by using the exact same inputs to the fractal algorithm.
These aspects are well known. The infinite-length, one-time pad is sort of the Panacea of encryption. Since the US prevents the export of such algorithms, research in this area is somewhat stunted. I have no commercial interest in this algorithm. Thus, I thought I might be able to help out in a field where business (American business, anyway) cannot.
Now, I repeat my question. Do any of you know of an integer-based fractal algorithm (that is, a fractal algorithm that doesn't include the division operator, and preferable doesn't include the multiplication operator with non-integer numbers)?
Chaotic algorithms (one type of fractal) are non-repeating, causal, and non-predictable. The idea is that a minute change in the input will result in a massive change in the output. The causality, of course, allows the results to be repeated, allowing for two-way encryption.
Chaotic algorithms, if properly chose, should result in excellent hashing algorithms. Of course, most chaotic algorithms are not truly chaotic, but merely approach chaos. Integer chaotic algorithms, I suspect, will have even more frequent repetition than floating point. That's not the point. The point is to get things Good Enough(tm).
I recall reading about a fractal algorithm about 2 years ago on slashdot where a Japanese researcher had discovered a fractal algorithm that doesn't repeat until 2^895 repetitions. This would make this algorithm sufficient for a hashing algorithm. Combine this with some of the techniques used in 3*DES, and you should be able to get a reasonably secure system with a key length that approaches infinity. Of course, such a system would be illegal to export from the US (I'm a US citizen, I'm afraid). However, a publication including said encryption algorithm should be covered by the 1st Amendment to the Consitution;-)
At any rate, your concept of a fractal algorithm repeating is, quite simply, wrong. There are very simple patterns that make fractal algorithms possible, but the fact of the matter is they are causal, non-predictable algorithms (at least, using any conventional math that I am aware of).
If anyone has any further interest in this, let me know. I'll need some non-US help implementing any algorithms. And, of course, their programming will have to be independent of any help from me (merely helping a foreigner understand encryption outside the confines of the 1st Amendment constitutes a crime equivalent to the trade of nuclear arms...).
On a related note, I was wondering if anyone is aware of a fractal algorithm (non-repeating, chaotic) that requires only integer math and truncation? I've got an idea for an encryption algorithm, and the basis of the algorithm is that it needs a reasonably quick fractal algorithm...
I hate to come to microsoft's defense on this one...but, they've dont as much for XML as any company with the possible exception of IBM. Sun keeps trying to fsck with microsoft's attempts to further XML standards, such as XSL (it took 2 extra years to get this standard approved, almost solely the result of Sun--besides, if you remember, MS invented XSL). You can knock MS for lack of security...for an unstable OS...for making applications that fill to consume 120% of your resources...but please don't knock them for screwing up the XML standards process. Really, the only company on par with them wrt XML is IBM...
I've done this very thing. I bought a couple of "silent" fans from PC Power & Cooling. They are very nice, and do make very little noise. But my machine is still almost as loud as before.
My hard drive, cpu, and video card fans make a horrible racket. Never mind the external CD-R (I leave that off unless I'm burning). I'm thinking of throwing my computers in a closet, and wiring the video, keyboard, & mouse wires through the wall. I shudder to think about the cost of the kvm repeater (if you run decently long video cables, you need a decent video amplifier, lest you run at 800x600).
In short, system fans will only get you so much. Anyone know of any particularly quiet hard drives? How about video cards that have decent hardware 3d, and perhaps a video tuner/capture?
Let's see. As I see it, there are a couple of requirements:
-real-time update of events (or near real-time) -client access from behind firewall -minimize load on servers.
Hmm. This is not an easy thing to do. If you don't want to poll, you're asking for a stateful connection to the server. Stateful connections are *expensive*. They should be avoided if possible. How often do you need updates? Is every 5 seconds excessive? If you increase that to a minute, 10000 requests per minute is not too big a load.
Assuming you want to stick with a stateful connection, have you looked at tunneling through the firewall over HTTP? If you're doing this from an applet, I'm assuming you're using Java. RMI supports tunneling through firewalls using HTTP.
Why not use one of the application servers that supports JMS? JMS is made for this type of data connection. Much of the burden of optimization is left to the application servers, which is good (I don't have to worry about it) and bad (you only get the optimizations the app server vendor provides).
In general, though, for web applications, you want to use stateless connections whenever possible. This implies that polling is the preferred method. At any rate, any two of the above three requirements can be easily met, but the three together are contradictory.
Having been a Motif programmer since the v1.0 days, I can wholeheartedly recommend against using a Motif-based framework. I've had experience with about a half dozen other GUIs, from MFC to InterViews to XForms, with a few others thrown in just for fun. Motif is absolutely the worst of the lot.
My favorite would have to be Swing (Java). However, I've seen many people run into serious problems with performance if they're not careful with their memory allocation (and, thus, garbage collection). It works reasonably well on all platforms, and is very easy to work with. This isn't the answer for everyone.
Another approach I've used a lot lately is building HTML front ends to JSP-based back ends. Again, this only works in certain situations, but it allows the client to be much smaller than with a Java solution.
I've also had the pleasure of building a few XML-based GUIs (XML files laid out the widgets, which were created from a Java program). Seems to me that this could be plugged in to several different GUI schemes (build a GTK or an MFC layer, separate your GUI from your core code, and voila!). That said, I'm not going to do it. And I would think it would be cheaper to use someone else's solution (read: buy it, or use an open source solution).
Why can I trade tapes between my friends, but I can't set up a factory to mass produce tapes of copyrighted material?
This is, quite simply, illegal. You can do it, just like you can set up a tape copying setup to mass produce copies of tapes. The fact that you can do it does not make it legal. The Fair Use Act (or whatever the hell it's called--please excuse my ignorance) states that you can make archival copies of your music (and video and software). You are not allowed to share that music/video/software with friends.
The only question of scale is whether or not the labels will try to track you down to recover lost income due to piracy. If you share your music with friends, you are pirating the music (unless, of course, you're copying live music from bands like the Grateful Dead and Phish, who explicitly allow non-commercial copying of their music).
Now, if Napster bans all copyrighted material in which the author has not given explicit permission to copy the music, I will still use Napster. As it is, I take pride in having a fairly extensive collection of legal mp3s on my system. I am a big fan of jam bands, of the likes of String Cheese Incident, Widespread Panic, Phish, and the Grateful Dead. These bands understood the ideas behind Napster long before Napster was even invented. Technologies like Napster provide a free method of advertising. Just as recordable audio and video cassettes spawned significantly higher revenue growth rates for music and videos, Napster and Gnutella will ultimately spawn new business for music and software. It is not a zero sum game. More (free) advertising leads to more actual sells.
One thing you can do is use a little javascript to strip any HTTP GET variables from the URL and add them to any hyperlink on the page. All links would then call a Javascript function instead of simply redirecting to a new URL. That Javascript function would be responsible for assembling the redirect URL, including the HTTP GET variables that were decoded from the original URL. It's a pain, but you only have to write the code once, and it *does* work...
That said, does WAP include ECMAscript (essentially, standard Javascirpt)? If not, then this solution won't work for WAP devices...
This isn't a question of, "Can Linux do this?". It's a question of, "Can the X Window System do this?". The answer is yes (for both questions, I might add).
Use the Accelerated-X server. They sell one that handles multiple monitors. I haven't checked it in a few years, but I had multiple monitors under Linux back in 1996. I think XF86 does it, too, but it's a pain in the ass to configure.
For the record, I think this was introduced to the X Window System way back in the late 80s. I'm getting old, so my memory ain't so great, but it seems like I remember seeing multiple monitor setups udner X as early as '88.
I think you'll find that running EJB on the middle/back tiers with an HTML/JSP interface for the front tier.
This method scales well, as HTML is stateless. If you need complex client-side behavior, then an HTML interface won't be sufficient. For this, an applet will work well.
I would not have the applet talk directly to the EJB server. Currently, EJB servers require the exact same JDK version to be run on the client and the server. This is because EJB has heavy dependencies upon Java serialization, which in turn can require the same JDK on each end. This is why you often see EJB used only to talk between the servlet/jsp layer (middle tier) and the persistance layer (back tier).
Solutions like this have proven to be an order of magnitude faster that ASP or Cold Fusion technologies. JSPs tend to run a tad slower than mod_perl or mod_php solutions. They're on the same order of magnitude, though. And JSPs *can* be a lot easier to work with once your code base gets large (assuming you've got good designers, that is). With EJB, you get lots of stuff for free (free logging of transactions, built-in security, and more).
Good luck with the project. It sounds like you're just getting started. May I recommend the E*Boss EJB server? It's free, and it is quite competitive (feature-wise) with the solutions from BEA and IBM. It's fast, and makes EJB deployment really easy.
As I understand things, magnetic gates will be *very* slow, compared to good old transistors. Of course, IANAMS (I am not a materials scientist). That assumes that these things work on a similar principle to core memory. Their claims on power consumption support this assumption.
That said, this would be perfect for things like space probes like Voyager. As I understand it, the space program is one of the last remaining manufacturers of core memory. In case you're too young to have seen core memory (I am--I once worked with a man that had his own computer museum), it consists of thousands of wires making a grid, with a little magnet at each intersection.
Re:Telnet is the only solution.
on
SSH v. SRP
·
· Score: 1
I was being quite serious. BackOrifice is a more secure way of remote administering a machine than PCAnywhere, if only because it is open source.
Security through obscurity is not security at all.
Slashdot Mirror
I remember being taught in school that the role of an operating system consists of managing system resources (which is, perhaps, why they call it an "operating system" and not an "operating environment"). Providing a GUI to the user does not consist of managing system resources. Managing memory, persistent storage, I/O, and the like--that is what an operating system does.
A GUI, like the Windows GUI, the Mac GUI, KDE, Gnome, or whatever, is simply an interface to the operating system. As a result, I can have a POSIX-complient interface to the OS in Windows--and bypass the Windows GUI altogether (ok, not completely--the posix "window" resides inside the Windows GUI).
Any other definition seems to me to be remaking history. To my knowledge, this has been the definition of an operating system since the creation of the term operating system. Of course, I'm relying upon second hand information here--I wasn't around back in the 50s and 60s to personally observe the entymology of "operating system" develop.
I've been using Dell's XGA+ monitor (1400x1050 resolution). It's absolutely stunning, and does not cause any strain on my admitably young eyes (I'm 29).
I am a screen real estate hog. Back in 1995, I bought my first laptop--an NEC w/ a 12.1" XGA monitor (1024x768)--so that I could write Unix programs on the go (it ran Linux flawlessly) without forking out for a Tadpole (~$20,000 at the time). The XGA+ monitor causes less strain on my eyes than the old NEC. Furthermore, I suspect you can increase the resolution to 1600x1200 without causing eye strain. However, your mileage may vary.
This, of course, is why I stated in my earlier post, "you can tell them to garbage collect on demand".
My point is that you have little control over when the garbage collector interrupts your program and garbage collects. As a result, you will want to keep this to a minimum. To keep it at a minimum, don't do things that require garbage collection (spuriously allocating objects).
GCJ often produces code that runs slower than Java code inside a decent JIT. I have rarely seen instances where GCJ is useful for anything but server-side code, and its limits with respect to dynamic class loading often make its performance worse than that of a good JIT.
The choice of the VM can have a tremendous impact on the speed of code. For instance, Sun's HotSpot VM still sucks for client side code. For server-side code, HotSpot (and its garbage collector) can improve apparent performance considerably.
This poster is right on. I've been developing Java libraries for a living for a number of years (ok, only 3+ years). These recommendations summarize things wonderfully. I couldn't have said it better myself.
One thing I would like to emphasize. Try to keep memory allocation to a minimum. Besides the obvious performance hit for allocating the memory and initializing the variables, you also run into issues with garbage collection. You really don't have too much control over garbage collection, either. I've seen one Java program in particular that would take seemingly random 30-second+ pauses on the MS JVM included with IE. It turned out that the only problem was that the garbage collector was running during these pauses. Garbage collection schemes are left up to the implementation of the JVM. Since you have little control over them (you can tell them to garbage collect on demand, at least), it is best to avoid turning control over to them unless absolutely necessary. Doing simple object pooling can enhance the performance of a program tremendously. For all you library developers out there, that means *don't* create immutable classes. Immutable classes prevent the use of object pooling.
In fact, color TFT does fine in plain sunlight, so long as you remove the backlight & backing (so that the LCD panel is transparent, when turned off).
If I recall correctly, these old grayscale screens didn't have backlights (similar to a digital watch). The backlight is never as strong as direct sunlight, and thus a laptop that requires the backlight cannot be seen in plain daylight.
It seems like some entrepreneur would make a laptop with a removable backlight and back. I seem to remember one company doing such a thing about 8 years ago so that the laptop could be used with an overhead transparency machine. It never sold very well, though.
I'm not so sure this post should have been moderated down. I think this poster made a valid point (that GNOME monkeys have better things to do with their time). It was a witty response to a rather stupid point, IMHO.
Oh well. Slashdot seems to be continuing its downward slope. . Remember the days when "http://www.slashdot.org" didn't work? You had to use "http://slashdot.org".
Except, of course, real sunlight makes viewing a laptop screen (even a TFT screen) almost impossible. Better to go find a nice, dark closet.
Even the G4-400 w/ 1 processor has Gigabit Ethernet.
Nice.
Mouse looks wierd, though.
Here in the US, natural gas makes sense. We've got loads of supplies (we're the Saudi Arabia of the natural gas world). It's cheap. It's very clean burning. Why don't we use it? No infrastructure.
A modest proposal: convert all civic vehicles to natural gas. This is already being done in many cities. However, we also need to require the motor pools for these cities to remove their filling stations. Make the civic vehicles fill up their cars at ordinary gas stations. As such, you will create a demand for gas stations that carry natural gas. Then, the early adopters can switch their vehicles to natural gas. Finally, Detroit will start making natural gas cars.
Once that happens, people will buy them. Even though there's a slight increase in danger with natural gas (estimates range from 30 to 150 additional deaths per year due to explosions from natural gas tanks), natural gas is cheaper and cleaner. The US can nationalize its fossil fuel consumption, removing our dependence on foreign oil. We could then tax the shit out of old gasoline (petrol for you non-US folk), using the tax revenues to invest into alternative fuel research.
Problems? Natural gas is very difficult to transport. Pipelines can't move gas--you have to liquify the stuff by putting it under immense pressure. That will cost the oil companies a lot of money. However, they should be happy to return energy production to the US. US is considered a low risk area for energy production--there's little risk the US government will be overthrown, with the new government nationalizing assets. Seems to me that the trade off would be very appealing for many companies.
I went to see the director's cut in the theater the same day I saw the original on TV. I thus had a good comparison with which to see what was added and deleted. As soon as the director's cut had ended, it was obvious. Why the hell would Deckard have dreamed about the unicorn, and his boss have left an origami unicorn behind, unless Deckard was himself a replicant? I mean, isn't it obvious?
I remember telling this to many people at the time. No one believed me. Alas, now I am vindicated.
Really, not that much changed between the director's cut and the regular. That dream sequence with the unicorn kind of stuck out, too. They kind of hit you over the head when they say something about being able to control replicants' dreams.
What I think is so amazing is how the entire film's meaning can change with a delta of about 30 seconds of video (forget the overdubbing...that was merely done to satisfy the Hollywood types). Kind of amazing. The film is 1000% better with the director's cut, as well.
At any rate, I'm glad that my hypothesis was correct. However, I'm kind of sad they had to make it definitive, though. One of the great things about art is that it can be interpreted in so many ways...
I have pondered this question quite seriously. I'm heading to Aberdeen, Scotland, in a few months. Here's the long and the short of it.
The main places you're seeing venture capital, and thus a thriving cutting edge tech schene, is Ireland (Dublin, I think..Ireland was out of the question for me for other reasons) & London. Both of these have a great high tech scene, with programmers making good money. DSL is being offered in both these places (think about it...no broadband, no high tech...). DSL is even available in parts of Aberdeen (this tipped the scales for me, as it's a better location for my spouse).
If you're using some of the latest technologies (JSPs, EJBs, CORBA, DCOM) and have some experience, you wages may even exceed those typical in the US. If you do training, you'll make significantly more (they're a little behind the US in terms of adoption of bleeding edge tech, so the demand for trainers is higher).
If you're a rank-and-file programmer, I think you'll easily find work making, by local standards, a lot of money. At this level, US counterparts make significantly more. That said, the recent startup scene in London and Ireland is supposedly hot enough that companies are beginning to offer stock options. I think this will get more common as the high tech labor force is further tightened. The European stock markets have done pretty well in the past few years, and the conditions seem to me to be similar to the US in the mid to late '80s (individual stock ownership, volume, etc...).
I don't think you'll beat the business climate in the Bay area, or Seattle, or Washington, DC. You might not beat it in any of the next six or seven cities in the US. That said, it's all good. You could probably choose some place like Tangiers and do fine in the high tech biz.
I think the idea was to build the encryption scheme first. I began a search for a suitable algorithm about 4 years ago. To date, the only algorithms I found that were suitable required floating point math. I didn't have the collective mind of slashdot behind me then. Now I do. So, if you have a *suggestion*, please let me know if you are aware of any integer fractal/chaos algorithms. No more, no less. I'm not trying to claim that I have some kick ass encryption scheme. I have an idea. I'd like to further the idea to a prototype. Until then, I still search.
Once done, I will turn over my work to the world. I don't want to hoard it. I merely want strong encryption that is fast enough to handle video streams. I also want it to be far more secure than any of the conventional 2-way hashing algorithms. Even the most robust of the 2-way hashing algorithms can be defeated with a finite amount of computing power. Use a key that approaches infinite lenght and you get a far more secure algorithm. This is the idea behind 3-des (as opposed to des, at least). Increased key length == more security. That said, a properly chosen fractal algorithm should approach randomness (or, at least, it should come close to being non-predictable). The randomness should allow for a key length that is more secure. The fractal part should help take care of the non-repeating part (that is, the predictability part). If it's a one-time pad, then all the better. The causal part of the fractal algorithm should allow both encryption and decryption, as both sides can generate the key by using the exact same inputs to the fractal algorithm.
These aspects are well known. The infinite-length, one-time pad is sort of the Panacea of encryption. Since the US prevents the export of such algorithms, research in this area is somewhat stunted. I have no commercial interest in this algorithm. Thus, I thought I might be able to help out in a field where business (American business, anyway) cannot.
Now, I repeat my question. Do any of you know of an integer-based fractal algorithm (that is, a fractal algorithm that doesn't include the division operator, and preferable doesn't include the multiplication operator with non-integer numbers)?
Chaotic algorithms (one type of fractal) are non-repeating, causal, and non-predictable. The idea is that a minute change in the input will result in a massive change in the output. The causality, of course, allows the results to be repeated, allowing for two-way encryption.
;-)
Chaotic algorithms, if properly chose, should result in excellent hashing algorithms. Of course, most chaotic algorithms are not truly chaotic, but merely approach chaos. Integer chaotic algorithms, I suspect, will have even more frequent repetition than floating point. That's not the point. The point is to get things Good Enough(tm).
I recall reading about a fractal algorithm about 2 years ago on slashdot where a Japanese researcher had discovered a fractal algorithm that doesn't repeat until 2^895 repetitions. This would make this algorithm sufficient for a hashing algorithm. Combine this with some of the techniques used in 3*DES, and you should be able to get a reasonably secure system with a key length that approaches infinity. Of course, such a system would be illegal to export from the US (I'm a US citizen, I'm afraid). However, a publication including said encryption algorithm should be covered by the 1st Amendment to the Consitution
At any rate, your concept of a fractal algorithm repeating is, quite simply, wrong. There are very simple patterns that make fractal algorithms possible, but the fact of the matter is they are causal, non-predictable algorithms (at least, using any conventional math that I am aware of).
If anyone has any further interest in this, let me know. I'll need some non-US help implementing any algorithms. And, of course, their programming will have to be independent of any help from me (merely helping a foreigner understand encryption outside the confines of the 1st Amendment constitutes a crime equivalent to the trade of nuclear arms...).
On a related note, I was wondering if anyone is aware of a fractal algorithm (non-repeating, chaotic) that requires only integer math and truncation? I've got an idea for an encryption algorithm, and the basis of the algorithm is that it needs a reasonably quick fractal algorithm...
I hate to come to microsoft's defense on this one...but, they've dont as much for XML as any company with the possible exception of IBM. Sun keeps trying to fsck with microsoft's attempts to further XML standards, such as XSL (it took 2 extra years to get this standard approved, almost solely the result of Sun--besides, if you remember, MS invented XSL). You can knock MS for lack of security...for an unstable OS...for making applications that fill to consume 120% of your resources...but please don't knock them for screwing up the XML standards process. Really, the only company on par with them wrt XML is IBM...
I've done this very thing. I bought a couple of "silent" fans from PC Power & Cooling. They are very nice, and do make very little noise. But my machine is still almost as loud as before.
My hard drive, cpu, and video card fans make a horrible racket. Never mind the external CD-R (I leave that off unless I'm burning). I'm thinking of throwing my computers in a closet, and wiring the video, keyboard, & mouse wires through the wall. I shudder to think about the cost of the kvm repeater (if you run decently long video cables, you need a decent video amplifier, lest you run at 800x600).
In short, system fans will only get you so much. Anyone know of any particularly quiet hard drives? How about video cards that have decent hardware 3d, and perhaps a video tuner/capture?
Let's see. As I see it, there are a couple of requirements:
-real-time update of events (or near real-time)
-client access from behind firewall
-minimize load on servers.
Hmm. This is not an easy thing to do. If you don't want to poll, you're asking for a stateful connection to the server. Stateful connections are *expensive*. They should be avoided if possible. How often do you need updates? Is every 5 seconds excessive? If you increase that to a minute, 10000 requests per minute is not too big a load.
Assuming you want to stick with a stateful connection, have you looked at tunneling through the firewall over HTTP? If you're doing this from an applet, I'm assuming you're using Java. RMI supports tunneling through firewalls using HTTP.
Why not use one of the application servers that supports JMS? JMS is made for this type of data connection. Much of the burden of optimization is left to the application servers, which is good (I don't have to worry about it) and bad (you only get the optimizations the app server vendor provides).
In general, though, for web applications, you want to use stateless connections whenever possible. This implies that polling is the preferred method. At any rate, any two of the above three requirements can be easily met, but the three together are contradictory.
-dan
Having been a Motif programmer since the v1.0 days, I can wholeheartedly recommend against using a Motif-based framework. I've had experience with about a half dozen other GUIs, from MFC to InterViews to XForms, with a few others thrown in just for fun. Motif is absolutely the worst of the lot.
My favorite would have to be Swing (Java). However, I've seen many people run into serious problems with performance if they're not careful with their memory allocation (and, thus, garbage collection). It works reasonably well on all platforms, and is very easy to work with. This isn't the answer for everyone.
Another approach I've used a lot lately is building HTML front ends to JSP-based back ends. Again, this only works in certain situations, but it allows the client to be much smaller than with a Java solution.
I've also had the pleasure of building a few XML-based GUIs (XML files laid out the widgets, which were created from a Java program). Seems to me that this could be plugged in to several different GUI schemes (build a GTK or an MFC layer, separate your GUI from your core code, and voila!). That said, I'm not going to do it. And I would think it would be cheaper to use someone else's solution (read: buy it, or use an open source solution).
But, please, don't use Motif.
This is, quite simply, illegal. You can do it, just like you can set up a tape copying setup to mass produce copies of tapes. The fact that you can do it does not make it legal. The Fair Use Act (or whatever the hell it's called--please excuse my ignorance) states that you can make archival copies of your music (and video and software). You are not allowed to share that music/video/software with friends.
The only question of scale is whether or not the labels will try to track you down to recover lost income due to piracy. If you share your music with friends, you are pirating the music (unless, of course, you're copying live music from bands like the Grateful Dead and Phish, who explicitly allow non-commercial copying of their music).
Now, if Napster bans all copyrighted material in which the author has not given explicit permission to copy the music, I will still use Napster. As it is, I take pride in having a fairly extensive collection of legal mp3s on my system. I am a big fan of jam bands, of the likes of String Cheese Incident, Widespread Panic, Phish, and the Grateful Dead. These bands understood the ideas behind Napster long before Napster was even invented. Technologies like Napster provide a free method of advertising. Just as recordable audio and video cassettes spawned significantly higher revenue growth rates for music and videos, Napster and Gnutella will ultimately spawn new business for music and software. It is not a zero sum game. More (free) advertising leads to more actual sells.
One thing you can do is use a little javascript to strip any HTTP GET variables from the URL and add them to any hyperlink on the page. All links would then call a Javascript function instead of simply redirecting to a new URL. That Javascript function would be responsible for assembling the redirect URL, including the HTTP GET variables that were decoded from the original URL. It's a pain, but you only have to write the code once, and it *does* work...
That said, does WAP include ECMAscript (essentially, standard Javascirpt)? If not, then this solution won't work for WAP devices...
This isn't a question of, "Can Linux do this?". It's a question of, "Can the X Window System do this?". The answer is yes (for both questions, I might add).
Use the Accelerated-X server. They sell one that handles multiple monitors. I haven't checked it in a few years, but I had multiple monitors under Linux back in 1996. I think XF86 does it, too, but it's a pain in the ass to configure.
For the record, I think this was introduced to the X Window System way back in the late 80s. I'm getting old, so my memory ain't so great, but it seems like I remember seeing multiple monitor setups udner X as early as '88.
I think you'll find that running EJB on the middle/back tiers with an HTML/JSP interface for the front tier.
This method scales well, as HTML is stateless. If you need complex client-side behavior, then an HTML interface won't be sufficient. For this, an applet will work well.
I would not have the applet talk directly to the EJB server. Currently, EJB servers require the exact same JDK version to be run on the client and the server. This is because EJB has heavy dependencies upon Java serialization, which in turn can require the same JDK on each end. This is why you often see EJB used only to talk between the servlet/jsp layer (middle tier) and the persistance layer (back tier).
Solutions like this have proven to be an order of magnitude faster that ASP or Cold Fusion technologies. JSPs tend to run a tad slower than mod_perl or mod_php solutions. They're on the same order of magnitude, though. And JSPs *can* be a lot easier to work with once your code base gets large (assuming you've got good designers, that is). With EJB, you get lots of stuff for free (free logging of transactions, built-in security, and more).
Good luck with the project. It sounds like you're just getting started. May I recommend the E*Boss EJB server? It's free, and it is quite competitive (feature-wise) with the solutions from BEA and IBM. It's fast, and makes EJB deployment really easy.
As I understand things, magnetic gates will be *very* slow, compared to good old transistors. Of course, IANAMS (I am not a materials scientist). That assumes that these things work on a similar principle to core memory. Their claims on power consumption support this assumption.
That said, this would be perfect for things like space probes like Voyager. As I understand it, the space program is one of the last remaining manufacturers of core memory. In case you're too young to have seen core memory (I am--I once worked with a man that had his own computer museum), it consists of thousands of wires making a grid, with a little magnet at each intersection.
I was being quite serious. BackOrifice is a more secure way of remote administering a machine than PCAnywhere, if only because it is open source.
Security through obscurity is not security at all.