Short of the long, we had to build, tweak and mess with all kinds of junk (tcpwrappers, ssh, ssl) before it went back on the network (yes, that donkey had been hacked before). So yes, there's lots of old Solaris still out there.
So why not simply put it on a private net, accessible only via ssh on a separate, more secure host? And only give the people that need it, access to that host?
If you have a *lab*, that's the way to go, in my opinion. You can't expect to put all kinds of weird equipment directly on the Internet, just because it happens to run on a general purpose computer.
Lab equipment shouldn't be IT's problem, it should be the lab peoples problem. It should be maintained and run by them. If they want to network the computers in the lab, it's their problem. *You* provide infrastructure *to* the lab, which means a ssh connection from a trusted host, a range of private IP numbers to use, and a single ethernet entry-point.
*They* provide switches, cabling, maintenance, etc... If the professors won't do it, there are grad students that do!
"Well, I don't know about you, but my coding speed isn't even remotely limited by my typing speed. If it is, you really need to learn to type."
Have you considered that perhaps you need to learn to code? Coding is like speaking, I can speak English faster than I can type it. I can also formulate code faster than I can type it.
If you can formulate code faster than you type, say you have a typing speed of 75 words per minute, and each code-line on average contains five words, that means you will write about 15 lines per minute, or 4500 lines per day (assuming you are efficient for only 5 hours). Divide that by 5 to allow for archaeology, design, debugging, and testing, and you can do about 1000 lines per day. If you have that kind of skill, you are one of the very few super-programmers in this world. From my CVS logs, I'm at about 50 lines per day. Still good, although loc metrics are pretty stupid anyway.
Here is where our opinions differ. Your mentality is why there is so much poorly documented code. The thing is, your not finished updating the API until you have updated the comments. You should be commenting WHILE your coding. The comments are just as important as any functional code.
No. Your mentality is why programs become a mess after maintenance. (*I* write perfect code, it's the bastards after me, that can't keep it that way). While what you say is good in theory, programmers will not update comments if they don't have the time! That's a fact, and it doesn't help the situation to blame others. If you want to make them update comments, keep you comments at a minimal level, and keep your comments useful.
Woah, stop the presses right here. You have misunderstood what I am saying. I'm talking about referencing the library the function is contained in at logical intervals not actually documenting the API with each use! The filename of a library should change rarely enough that this shouldn't be a big deal, in fact if you document these in a standard way you can whip up a script in about 5 mins to change these for you throughout all your sourcecode. This tells me where to look for your function and THERE I will find the updated api comments (these should be updated BEFORE the new api is written and both should be done before a commit.
It's funny you want to do that. Emacs, vi, and almost all IDE's has that functionality, without needing to write extra comments, or whipping up small scripts. Learn to use the tools you are equipped with, instead of polluting the source code with redundant information!
Dear god no, mixed case leads to gobs of errors from nothing more than incorrect case.
Huh. What kind of errors are you talking about? Compile-time errors? They are not exactly the main problem when writing reliable software, now are they?
[Still about not using mixed case]:This one thing can double the speed at which you write and debug code.
Well, I don't know about you, but my coding speed isn't even remotely limited by my typing speed. If it is, you really need to learn to type.
Next is this BS about self-documenting code. Code is not meant to be self documenting.
Of course it is.
Proper scoping will prevent names from clashing. Write the most efficient function you can and choose names that make sense in the smallest scope possible.
Yes
And then *gasp* COMMENT the code well. You can even include comments near where a variable or function is to indicate in plain English what it is for! Believe it or not, code should not be self commenting, code is not a spoken language and is a poor medium to use to express messages between people who speak one.
I'd rather say: don't bother. Comments should be limited to
The purpose of the code
The basic ideas behind the implementation, perhaps with a link to relevant literature
And if needed, maybe a short explanation of unusual data-structures and/or algorithms, but see 2.
Specifically, if you create an API, don't document it too much. API's change, and your comments will get out of sync with reality. If the API ever stabilizes, and lots of people start using it, that's the time to start thinking about proper documentation. Because that's the time you don't want to change anything. Look at GTK for example. It's highly succesful, but still not perfectly documented. And still changing!
Nothing works better than your actual spoken language in complete sentence structures in a comment to remind you what a variable or function is or what a block of code does.
Exactly. And therefore comments should be limited to a short explanation at the top or bottom of the file, or in a separate document. You don't need to add too many details, as those will change. Give the basic ideas instead.
and please for god sake comment EVERY call of a function that is not part of the standard c libraries within 20 lines explaining where it came from! Doing this will not only easier for people who know the project well to see what is happening and where to refer to but it will also help those who are NOT familiar jump in and possibly change one thing.
For the love of God! Please don't! So when the API changes, you have approximately 2 billion places to update comments to get them in sync with reality. Just don't do that! Keep comments in one place, and one place only!
Believe it or not, I do not want to read your 100,000 lines of source to make one change. I want to be able to look at the main routine and b-line right from there to the portion of the code I need using the commented function calls.
Believe it or not. I don't want to change comments in 100,000 lines of source for a minor API change, that would otherwise result in 5 edits. Neither do I want to grep through them when trying to find out what needs to change. And I know where I come from. At my last job I was thrown into a project with about 60MB of code made unmaintainable by people following the commenting practices you preach, followed by at least 10 years of maintenance work by different people.
It was nearly impossible to find out what a given piece of code did, because you would have 30 or so separate places that documented the code, none of them which got it right, because 10 or 20 people had changed the code later. At every edit (and I only added new functionality), the code shrunk because useless comments were deleted first, and useless or obtuse code were fixed or removed later. The code was a total disaster-area of well-meaning but idiotic over-engineering, followed by real-life maintenance work by people totally unequipped to understand the resulting mess. This is software archeology in practice!
Seth's proposed improvements over the current X11/Xorg server sound very nice, but what about the core speed issue in X. X has come leaps and bounds over the past 5 years or so but still "feels" extremely sluggish compared to a similarly equipped Windows XP machine. I know it's comparing apples to oranges since X is network-based but still...
Anyone have any ideas if he plans to address performace as well?
Actually, I have never found X to be sluggish. What used to be an issue, was the unresponsiveness I experienced when I e.g. couldn't move the X cursor because some other process ate all the CPU, etc... Fortunately, I haven't had anything like that in the last years.
I would recommend that you upgrade to the latest 2.6.10 kernel, and see if it makes a difference. I actually installed w2k recently. I found it much more sluggish than using gnome in debian, on the same machine.
(Although, to get serious for a moment, with good headphones and appropriately clever signal processing software, you really only need two channels: one for each ear. And maybe a subwoofer. The signal processing software mimics the various psychoacoustic cues you get from sounds in various directions being filtered by your external ear flaps, bouncing off your shoulders, and all the other subtle cues that let you localize a sound source in 3D.)
And a gyro sensor so you won't be fooled when you move your head around...
Ever wonder why GPUs are such a big deal and sound cards are such an after thought? It's all about numbers. ATI and nVidia can increase clock speed and double memory and make it look really impressive. Sound cards can't really do that.
Sure they can. Soundcards can add inputs and outputs. And they can improve quality. But only musicians need or want that.
For the typical users, modern sound cards are perfectly adequate for doing what people use them for: playing sound! (whether it is in stereo or some surround sound scheme)
For desktop users, modern graphic cards are also perfectly adequate. But gamers still want faster and better. And there are a lot more gamers than musicians.
By the way: Adding RAM or processing power wouldn't help much, though. Musicians want low-latency, not larger buffers. And software-samplers, synths, and effects have pretty much won the battle with soundfonts and on-board DSP-effects in this market. Your soundcard does I/O, your CPU does processing! A real solution to offload the CPU for DSP might be popular though, but it shouldn't really have anything to do with the sound card (the cell processor perhaps?)
that's what I thought of too, but it would be soooooo much better if you displayed the data, and had a guy at each end, one saying one, zero, zero, one.... and the other typing it in.
And of course, the guy listening to this on the other end, will morse 0 or 1 with a flashlight to someone on a mountain that will in turn use semaphore flags to relay them to a guy that will throw pies at either a man or a woman (depending on zero or one). A blindfolded guy will listen to the them and put zeros or ones down on notes which will be transported by carrier pigeons to a fax-machine that will send them to a computer fax-modem that will send them over a quantum-encrypted line to a bunker where it will detonate small or large bombs that will be recorded by some seismic equipment that will write the data in standard seismic data-files on tape-reels, which will be transported by courier on a plane to a laboratory that will interpret the tapes and send the decoded message to the final destination as uuencoded mime email.
I don't want to be unfair (even though this is/. which is anti-MS), but is this really shaping up as a everyone-but-Microsoft vs. Microsoft battle? Or (and I did RTFA), is it more a matter of which technical standard is better?
None of the above. It's just that a bunch of browser makers are lazy and whiney, and don't want to implement XForms. To make their position seem more reasonable, they instead blame their users for being slow to upgrade their browsers.
But they all know that if XForms isn't adopted soon, surely Microsoft will come up with a "better" solution. So instead, the rest of them try to agree on something that microsoft wouldn't come up with. They all know it's inferior, but at least is here right now!
It doesn't really need to. chroot is a unix-ism to circumvent the inherent insecurity that comes from the necessity under unix to be root to do "useful" things (like bind to low network points).
Ehh no. If you want to bind to low network points, you can do that as root and then setuid(3) to another low-privilege user, or by getting a file-descriptor from another (more privileged) process, or you could get that capability granted to you by a startup-script, or another process. For web-servers, almost everybody would use the simplest solution: setuid(3).
Since the Windows security model is completely different (ie: it's more complicated than unix's "if UID != 0 then apply_security()"), the concept of chroot doesn't really need to exist.
No. The problem you mentioned isn't why chroot is useful. chroot isn't needed on unix either (in theory). Since most web-servers on unix runs as some non-privileged user anyway (as opposed to IIS which has system privileges), you are extremely way off the target.
chroot is there simply because all software has bugs. Even if there is a critical security hole in e.g. the operating system, that results in a remote vulnerability, and someone takes advantage of this, they still can't escape from the chroot'ed environment. Unless there are holes in the chroot functionality too (which could be true).
Good security practice is to do a total overkill, i.e you build your security in layers. You have one (or more) firewall(s), preferably both at the packet filtering level and the application level. You run every service with as few privileges as possible. You put them in a chrooted environment. You lock down everything you don't need. You run it on a dedicated machine (and/or use something like UML). And then you can start worrying about keeping up-to-date on patches.
By the way, the unix security model you described might have been correct in the 70's. It isn't anymore. Different unixes might do different things, but most certainly everyone will at least have various ways of escaping the need to be root to do useful stuff, e.g. capabilities, passing of file-descriptors, etc...
i just hope that isp's dont start charging double if you have multiple computers connected to the same connection. just like the software, your not paying per processor, its buy machine.
But they do. The "solution" to this problem is called NAT.
The same hole exists in java. It's called JNI (or even RMI, Corba, SOAP, etc...).
If you want a language that has no "security holes", you'd better build a computer without them too. Some way or another you have to hit the bare metal in the end...
Any programmer worth a damn knows to develop multi-platform if they want to make any money.
You don't need to be a programmer to figure out there's one dominant platform out there. It's Microsoft Windows. While you may get a few percent extra customers from being multi-platform, it often isn't worth the trouble (and extra costs).
Go ahead and make your game in DirectX, good luck getting that to work on a PS2 or Gamecube, let alone Linux and Mac.
If you are working for a big company that can afford selling shrink-wrapped boxes, then you definitely would consider some game consoles, yes! If you are a shareware developer, or doing e.g. online games. No. The important thing is to get your game out the widest possible audience as soon as possible. Adding portability at the cost of development time is very a bad idea if you are in the game business.
But the question I asked myself is, what would be the consequences of the outburst of a "nearby" star. I mean, would the shockwave be big enough to reach earth? Will the gases and radiations be able to reach earth??
Well, if it is near enough, we would probably see a lot of radiation. So keep your sunblock ready if it should happen in the next million years. I am doubtful about the gases, though...
Personally, I'm more worried about traffic accidents, though...
Well, creating "lust" in an AI is certainly a worthwile goal. Most of human behaviour is governed by "lust". E.g. we are curious because we get satisfaction from learning new things. We are nice to each other because we get satisfaction from gratitude. And some people (e.g. Freud) seem to think most of this is connected to our lust to fuck someone.
But then again, creating "lust" in an AI might be a bit harder than increasing the value of some evaluation function. But then again, maybe it isn't? If it looks like a duck, quacks like a duck, even reasons like a duck, is it then a duck?
If AI can be achieved simply by mimicking our own behaviour, it can actually be bad news. That means it might not be possible to create some simple reasoning engine. We actually have to work our way in increasingly complicated models, untill we no longer can tell the difference between it, and ourselves (or some other intelligent being). This could easily take thousands of years...
It's true on both time and causality.
Alan says so himself here
Thanks. I stand corrected. And the article was a fun read too. I've even used the corridor-approach to debugging myself. Good to see that I'm not alone.
believe it or not in school we are being taught LISP.
Lucky you. Maybe you can learn something useful then, instead of doing the trendy stuff.
So far the teacher said the only use it for AI.
Unlucky you. You have an idiot teacher that can't even explain why lisp is so great. Think about this: AI is the hardest problem computer scientists ever need to solve. If a language is good enough to be used for research in AI, it's good enough to solve most any other problem too.
The only problems with lisp are cultural. Many lispers are elitists who don't care for stuff other programmers need, such as distribution of binaries, portability between lisp-implementations, a standard, etc... And most mundane programmers hate lisp because it has lots of silly parentheses.
I don't really care for it, good thing its only once a week.
Exactly an example of the kind of discussion the original poster intended. The diagram shows Simula as a precursor for SmallTalk. Which is true if you look at time, but probably not if you look at causality. It's very likely the people who invented SmallTalk didn't even know about Simula, or realized that it was "object-oriented".
C++ on the other hand, was heavily influenced by Simula, as Stroustrup has told in numerous interviews, books, articles, etc...
Whatever you mean by Python being the most recent strongly-typed language, I can't even imagine. If you haven't found a newer strongly typed language, you can't have looked very far. Wether Python really is strongly typed is also up for discussion, but mostly because there is no clear definition of what this implies.
OFX is based upon SGML and, like XML, it is an attempt to take the best features of SGML and remove much of the associated complexity. OFX is not technically an XML application. The syntax of OFX differs from that set out for XML applications in that OFX omits end-tags
It's SGML, not XML. Unless you insist on doing it the hard way with a real SGML parser, I can't see what's wrong with using your own hand-rolled one. As you've already recognized yourself, it shouldn't be too hard.
Other alternatives would be to have an a preprocessor that converts it to XML, or maybe use some too-tolerant XML-parser. On the other hand, if the file format isn't XML, I can't see why it would be easier to treat it as if it were.
Am I missing something here, or is this truly a file format that is broken as a feature?
Mu.
Yes, you are missing the distinction between XML and SGML. No, it's not broken as a feature, it just predates XML.
Then you just wait for all the orders to come in. After you have been saturated with orders, you then take that address list you just built (which contains the addresses of all the idiots and old people), and you prodeed to hire our 'contracts' to 'deal with' the problem.
Nope, that won't work. The only thing you would have achieved is to rid the world of a few people responding to spam. But even if you got rid of, say 70% of the people responding to spam, it wouldn't affect the economy of the spammers much.
Because spam is essentially free to send out, you will still have 30% of the idiots left, who will continue to send money into the system. Thus, you may have reduced the spammers income a bit, but you have not reduced their costs. In the meantime, spam technology makes it even cheaper to be a spammer, and new users/idiots gain access to the Internet.
To be really effective, there is only one solution. Scrap e-mail. It's dead. Anything that allows someone to reach thousands of people with a net cost of 0 is doomed to have the same problem. I've done this myself. If someone needs to reach me, they can use snail-mail, or use the phone. And by the way, ask your local cell-phone companies to increase the cost of SMS-messages... It's getting too cheap these days!
Does this mean that in a few years you will be able to charge $2000 for a transistor audio amplifier to a dorky audiophile who claims that "crossbar amps does not sound as good as old technology" ?
Nope. Nanocircuits ain't too good for amplifiers. Unless you want to measure the output in nanowatts... But regardless of that, my quick glance of the whitepaper someone linked to back earlier in the thread, doesn't seem to indicate that crossbar latches would even work as amplifiers.
But maybe you can sell your old-fashioned transistor-computer. I'm sure most tube-computers are pretty expensive today (although perhaps not as much as they originally were).
Slashdot Mirror
So why not simply put it on a private net, accessible only via ssh on a separate, more secure host? And only give the people that need it, access to that host?
If you have a *lab*, that's the way to go, in my opinion. You can't expect to put all kinds of weird equipment directly on the Internet, just because it happens to run on a general purpose computer.
Lab equipment shouldn't be IT's problem, it should be the lab peoples problem. It should be maintained and run by them. If they want to network the computers in the lab, it's their problem. *You* provide infrastructure *to* the lab, which means a ssh connection from a trusted host, a range of private IP numbers to use, and a single ethernet entry-point.
*They* provide switches, cabling, maintenance, etc... If the professors won't do it, there are grad students that do!
If you can formulate code faster than you type, say you have a typing speed of 75 words per minute, and each code-line on average contains five words, that means you will write about 15 lines per minute, or 4500 lines per day (assuming you are efficient for only 5 hours). Divide that by 5 to allow for archaeology, design, debugging, and testing, and you can do about 1000 lines per day. If you have that kind of skill, you are one of the very few super-programmers in this world. From my CVS logs, I'm at about 50 lines per day. Still good, although loc metrics are pretty stupid anyway.
No. Your mentality is why programs become a mess after maintenance. (*I* write perfect code, it's the bastards after me, that can't keep it that way). While what you say is good in theory, programmers will not update comments if they don't have the time! That's a fact, and it doesn't help the situation to blame others. If you want to make them update comments, keep you comments at a minimal level, and keep your comments useful.
It's funny you want to do that. Emacs, vi, and almost all IDE's has that functionality, without needing to write extra comments, or whipping up small scripts. Learn to use the tools you are equipped with, instead of polluting the source code with redundant information!
Huh. What kind of errors are you talking about? Compile-time errors? They are not exactly the main problem when writing reliable software, now are they?
[Still about not using mixed case]:This one thing can double the speed at which you write and debug code.
Well, I don't know about you, but my coding speed isn't even remotely limited by my typing speed. If it is, you really need to learn to type.
Next is this BS about self-documenting code. Code is not meant to be self documenting.
Of course it is.
Proper scoping will prevent names from clashing. Write the most efficient function you can and choose names that make sense in the smallest scope possible.
Yes
And then *gasp* COMMENT the code well. You can even include comments near where a variable or function is to indicate in plain English what it is for! Believe it or not, code should not be self commenting, code is not a spoken language and is a poor medium to use to express messages between people who speak one.
I'd rather say: don't bother. Comments should be limited to
Specifically, if you create an API, don't document it too much. API's change, and your comments will get out of sync with reality. If the API ever stabilizes, and lots of people start using it, that's the time to start thinking about proper documentation. Because that's the time you don't want to change anything. Look at GTK for example. It's highly succesful, but still not perfectly documented. And still changing!
Nothing works better than your actual spoken language in complete sentence structures in a comment to remind you what a variable or function is or what a block of code does.
Exactly. And therefore comments should be limited to a short explanation at the top or bottom of the file, or in a separate document. You don't need to add too many details, as those will change. Give the basic ideas instead.
and please for god sake comment EVERY call of a function that is not part of the standard c libraries within 20 lines explaining where it came from! Doing this will not only easier for people who know the project well to see what is happening and where to refer to but it will also help those who are NOT familiar jump in and possibly change one thing.
For the love of God! Please don't! So when the API changes, you have approximately 2 billion places to update comments to get them in sync with reality. Just don't do that! Keep comments in one place, and one place only!
Believe it or not, I do not want to read your 100,000 lines of source to make one change. I want to be able to look at the main routine and b-line right from there to the portion of the code I need using the commented function calls.
Believe it or not. I don't want to change comments in 100,000 lines of source for a minor API change, that would otherwise result in 5 edits. Neither do I want to grep through them when trying to find out what needs to change. And I know where I come from. At my last job I was thrown into a project with about 60MB of code made unmaintainable by people following the commenting practices you preach, followed by at least 10 years of maintenance work by different people.
It was nearly impossible to find out what a given piece of code did, because you would have 30 or so separate places that documented the code, none of them which got it right, because 10 or 20 people had changed the code later. At every edit (and I only added new functionality), the code shrunk because useless comments were deleted first, and useless or obtuse code were fixed or removed later. The code was a total disaster-area of well-meaning but idiotic over-engineering, followed by real-life maintenance work by people totally unequipped to understand the resulting mess. This is software archeology in practice!
Actually, I have never found X to be sluggish. What used to be an issue, was the unresponsiveness I experienced when I e.g. couldn't move the X cursor because some other process ate all the CPU, etc... Fortunately, I haven't had anything like that in the last years.
I would recommend that you upgrade to the latest 2.6.10 kernel, and see if it makes a difference. I actually installed w2k recently. I found it much more sluggish than using gnome in debian, on the same machine.
And a gyro sensor so you won't be fooled when you move your head around...
That would result in aliasing. But how about spline-based audio? Now, that's a thought...
Sure they can. Soundcards can add inputs and outputs. And they can improve quality. But only musicians need or want that.
For the typical users, modern sound cards are perfectly adequate for doing what people use them for: playing sound! (whether it is in stereo or some surround sound scheme)
For desktop users, modern graphic cards are also perfectly adequate. But gamers still want faster and better. And there are a lot more gamers than musicians.
By the way: Adding RAM or processing power wouldn't help much, though. Musicians want low-latency, not larger buffers. And software-samplers, synths, and effects have pretty much won the battle with soundfonts and on-board DSP-effects in this market. Your soundcard does I/O, your CPU does processing! A real solution to offload the CPU for DSP might be popular though, but it shouldn't really have anything to do with the sound card (the cell processor perhaps?)
And of course, the guy listening to this on the other end, will morse 0 or 1 with a flashlight to someone on a mountain that will in turn use semaphore flags to relay them to a guy that will throw pies at either a man or a woman (depending on zero or one). A blindfolded guy will listen to the them and put zeros or ones down on notes which will be transported by carrier pigeons to a fax-machine that will send them to a computer fax-modem that will send them over a quantum-encrypted line to a bunker where it will detonate small or large bombs that will be recorded by some seismic equipment that will write the data in standard seismic data-files on tape-reels, which will be transported by courier on a plane to a laboratory that will interpret the tapes and send the decoded message to the final destination as uuencoded mime email.
None of the above. It's just that a bunch of browser makers are lazy and whiney, and don't want to implement XForms. To make their position seem more reasonable, they instead blame their users for being slow to upgrade their browsers.
But they all know that if XForms isn't adopted soon, surely Microsoft will come up with a "better" solution. So instead, the rest of them try to agree on something that microsoft wouldn't come up with. They all know it's inferior, but at least is here right now!
Ehh no. If you want to bind to low network points, you can do that as root and then setuid(3) to another low-privilege user, or by getting a file-descriptor from another (more privileged) process, or you could get that capability granted to you by a startup-script, or another process. For web-servers, almost everybody would use the simplest solution: setuid(3).
Since the Windows security model is completely different (ie: it's more complicated than unix's "if UID != 0 then apply_security()"), the concept of chroot doesn't really need to exist.
No. The problem you mentioned isn't why chroot is useful. chroot isn't needed on unix either (in theory). Since most web-servers on unix runs as some non-privileged user anyway (as opposed to IIS which has system privileges), you are extremely way off the target.
chroot is there simply because all software has bugs. Even if there is a critical security hole in e.g. the operating system, that results in a remote vulnerability, and someone takes advantage of this, they still can't escape from the chroot'ed environment. Unless there are holes in the chroot functionality too (which could be true).
Good security practice is to do a total overkill, i.e you build your security in layers. You have one (or more) firewall(s), preferably both at the packet filtering level and the application level. You run every service with as few privileges as possible. You put them in a chrooted environment. You lock down everything you don't need. You run it on a dedicated machine (and/or use something like UML). And then you can start worrying about keeping up-to-date on patches.
By the way, the unix security model you described might have been correct in the 70's. It isn't anymore. Different unixes might do different things, but most certainly everyone will at least have various ways of escaping the need to be root to do useful stuff, e.g. capabilities, passing of file-descriptors, etc...
Well, perhaps you think so. But it would be just as wrong. An electron isn't made of leptons anymore than a swede is made up by europeans.
So what exactly is it Intel is offering?
But they do. The "solution" to this problem is called NAT.
If you want a language that has no "security holes", you'd better build a computer without them too. Some way or another you have to hit the bare metal in the end...
You don't need to be a programmer to figure out there's one dominant platform out there. It's Microsoft Windows. While you may get a few percent extra customers from being multi-platform, it often isn't worth the trouble (and extra costs).
Go ahead and make your game in DirectX, good luck getting that to work on a PS2 or Gamecube, let alone Linux and Mac.
If you are working for a big company that can afford selling shrink-wrapped boxes, then you definitely would consider some game consoles, yes! If you are a shareware developer, or doing e.g. online games. No. The important thing is to get your game out the widest possible audience as soon as possible. Adding portability at the cost of development time is very a bad idea if you are in the game business.
Well, if it is near enough, we would probably see a lot of radiation. So keep your sunblock ready if it should happen in the next million years. I am doubtful about the gases, though...
Personally, I'm more worried about traffic accidents, though...
But then again, creating "lust" in an AI might be a bit harder than increasing the value of some evaluation function. But then again, maybe it isn't? If it looks like a duck, quacks like a duck, even reasons like a duck, is it then a duck?
If AI can be achieved simply by mimicking our own behaviour, it can actually be bad news. That means it might not be possible to create some simple reasoning engine. We actually have to work our way in increasingly complicated models, untill we no longer can tell the difference between it, and ourselves (or some other intelligent being). This could easily take thousands of years...
The fast way could possibly be uploading...
Thanks. I stand corrected. And the article was a fun read too. I've even used the corridor-approach to debugging myself. Good to see that I'm not alone.
That shouldn't really surprise you too much, considering Niklaus Wirth was the man behind Pascal, Modula, Modula-2, and Oberon.
Pascal is dead. Object Pascal with various other extensions lives on. It's called Delphi.
What do schools use now as the teaching language? Surely not C. I have nothing against it but it isn't for beginners.
They use Java. Or maybe soon C#
Lucky you. Maybe you can learn something useful then, instead of doing the trendy stuff.
So far the teacher said the only use it for AI.
Unlucky you. You have an idiot teacher that can't even explain why lisp is so great. Think about this: AI is the hardest problem computer scientists ever need to solve. If a language is good enough to be used for research in AI, it's good enough to solve most any other problem too.
The only problems with lisp are cultural. Many lispers are elitists who don't care for stuff other programmers need, such as distribution of binaries, portability between lisp-implementations, a standard, etc... And most mundane programmers hate lisp because it has lots of silly parentheses.
I don't really care for it, good thing its only once a week.
Try to pay attention. You might learn something.
C++ on the other hand, was heavily influenced by Simula, as Stroustrup has told in numerous interviews, books, articles, etc...
Whatever you mean by Python being the most recent strongly-typed language, I can't even imagine. If you haven't found a newer strongly typed language, you can't have looked very far. Wether Python really is strongly typed is also up for discussion, but mostly because there is no clear definition of what this implies.
It's SGML, not XML. Unless you insist on doing it the hard way with a real SGML parser, I can't see what's wrong with using your own hand-rolled one. As you've already recognized yourself, it shouldn't be too hard.
Other alternatives would be to have an a preprocessor that converts it to XML, or maybe use some too-tolerant XML-parser. On the other hand, if the file format isn't XML, I can't see why it would be easier to treat it as if it were.
Am I missing something here, or is this truly a file format that is broken as a feature?
Mu. Yes, you are missing the distinction between XML and SGML. No, it's not broken as a feature, it just predates XML.
Nope, that won't work. The only thing you would have achieved is to rid the world of a few people responding to spam. But even if you got rid of, say 70% of the people responding to spam, it wouldn't affect the economy of the spammers much.
Because spam is essentially free to send out, you will still have 30% of the idiots left, who will continue to send money into the system. Thus, you may have reduced the spammers income a bit, but you have not reduced their costs. In the meantime, spam technology makes it even cheaper to be a spammer, and new users/idiots gain access to the Internet.
To be really effective, there is only one solution. Scrap e-mail. It's dead. Anything that allows someone to reach thousands of people with a net cost of 0 is doomed to have the same problem. I've done this myself. If someone needs to reach me, they can use snail-mail, or use the phone. And by the way, ask your local cell-phone companies to increase the cost of SMS-messages... It's getting too cheap these days!
Nope. Nanocircuits ain't too good for amplifiers. Unless you want to measure the output in nanowatts... But regardless of that, my quick glance of the whitepaper someone linked to back earlier in the thread, doesn't seem to indicate that crossbar latches would even work as amplifiers.
But maybe you can sell your old-fashioned transistor-computer. I'm sure most tube-computers are pretty expensive today (although perhaps not as much as they originally were).