Spam is currently being addressed, at least in germany. IIRC, it is actually an EU directive as well.
Kiddie-Porn wasn't ever legal, of course. The existing loopholes are of the kind that cannot be fixed legislatively by a single country (or the EU, for that matter).
All your problems with changing IP addresses and stuff are already solved:
A user agent that wishes to authenticate
itself with a server -- usually, but not
necessarily, after receiving a 401 response--does
so by including an Authorization request-header
field with the request.
RFC 2616, HTTP 1.1
Why the f**k is it so hard to understand how HTTP works? Why do people reinvent it, badly?
It is really simple: When a user wants to see something, he issues a GET. This is idempotent and doesn't carry any kind of state except what the client explicitly provides, like the URI, the preferred format and language, and his credentials. If he wants to perfom some destructive operation, he uses POST, PUT or DELETE. Again, all that's neccessary for the server to know is in the headers and the payload, where applicable.
Listen, web developers: Using HTTP the way it was meant to actually works. You don't need kludges like cookies or GET with lots of parameters where what you do has nothing to do with GETting a resource. It even makes lots of nasty problems go away, like the back-button breaking your app. Try reading and understanding the actual specs, or the diss of the guy who wrote (some of) them.
When you have user log-in to a particular part of the site, you need to store username, password information, and some other session variables in a cookie, so that on subpages within the part that needs to be logged into can check to see is the user is properly logged in. I like to check to see if the user is the actual user I think they are.
Why wouldn't you use HTTP authentication to authenticate users of your HTTP app?
I guess you've never used php before.
When your tool makes it hard to use the web architecture properly, maybe you should use a better one. Working against the fundamentals of the environment you are in (like statelessness) will cause you a lot of headache in the long run, like this example shows.
Java (and other "restrictive" languages) only prevent a small class of errors, e.g., memory leaks.
About every language except C and C++ (including some that are more "enabling" than "restrictive") effectively prevent code injection by buffer overflows and format string errors, which make for a significant portion of exploits. Of course, a system is not automatically safe if you get rid of these problems, but scince logic or algorithmic errors (or plain stupidity:-) are possible in C as well, you can only win by not using it.
Wow, that article was really enlightening. *cough* However, here's what I think should be the first item in every "Best Practives for Programming in C" list:
Dont programm in C unless you have a really good reason to.
Good reasons are:
You are extending an operating system kernel or other huge system that is written in C.
You are writing a library and expect it to be used from several other languages. C is the lowest common denominator, every language has a C interface.
In all other cases, use a high-level language. Users and admins will be grateful for not having to download patched versions every time a buffer overflow or format-string error is found. You will like being able to concentrate on the core problem you want to solve instead of dealing with all the detail C and its libraries left for you to care about. If you need speed, use a high-level language with a good compiler. If you need to bit-fiddling, use a high-level language with good bit-fiddling support. They exist, and there's even some overlap between them.
Re:$1550 just to use it? No thanks.
on
QT 3.2 Released
·
· Score: 2, Informative
Well, we'll see how Trolltech will react when the GPLed Windows version starts to get real. Qt/X11 probably would not be under the GPL were it not for someone starting a free clean-room reimplementation during the great QPL flamefest (IIRC it was called Project Harmony. It was abandoned when Trolltech released the GPL version, unlike Gnome, which has the same origin).
I for one don't think that a free Windows version would kill Trolltech. The people using Qt/Win right now are unlikely to use it, and most will probably simply still paying for the commercial license.
Now, does this mean that Windows contain Unix-code and if so, does this mean that SCO owns Microsoft?
Well, wasn't Xenix the result of a cooperation between SCO and MS? Who knows what valueable IP from that deal is still in XP?! So no wonder that MS is not releasing Windows under the GPL, it's all SCO's fault!
What's the fastest runtime for Python? Can it translate to C code?
Nope, it goes directly to machine language. Plain old CPython with Psyco, that is.
My personal quest has been for a productive, portable language that's efficient enough for high-end gaming applications.
Try Lisp. No, seriously. Think GCs and (native-code) compilers with 40 years of optimization, together with a really high-level, productive language. See this example where it seems to have worked quite well.
So use Epiphany or Galeon, if you don't mind Gnome. Or maybe Skipstone, if that is still alive. Even Firebird is supposed to be snappier, even if I could not see much improvement myself.
Frankly, I guess the language is still rather shitty. Problem is, it is there,
and lots of apps use it, especially custom in-house stuff. Somebody in Munich
will probably perform a Schuhplattler out of joy when he hears about that.
Right. Just like Windows XP Pro is only $299 if your time has no value. Your point?
Re:Are they reinventing the wheel ?
on
Eclipse in Action
·
· Score: 1
I don't know about your way of using Emacs much, but unless it comes with
the most flexible mail and newsreader, a sane, extensible shell that also
works on Windows, an addressbook that integrates with the IRC utility,
the ability to write, debug and run extensions and customizations without
restarting, support for C, C++, Java, Common Lisp, Python, Ruby, HTML, XML,
XSLT and Make even when mixed in one file, good performance over ssh, usability
in text-only types of environments, an mp3 player, web browsing, and
Tetris, it won't replace Emacs on my boxes any time soon.
It might be an OK replacement for Emacs-as-an-IDE, but Emacs is more. It is
more compareble to KDE or Gnome plus a lot of third-party apps and real
pervasive interoperability, and while
there is probably not much making it impossible to extend Eclipse in that
direction (except the no-window-system part probably), nobody has done it
yet. Wake me up again when this has changed.
Allegro CL's Common Graphics is unfortunatly not portable - for portable Lisp
GUIs consider Xanalys LispWorks,
which runs on
Windows, Unix (Linux, FreeBSD, lots of commercial ones) and
Mac OS X, including the GUI. It is a really fine product, and way less pricey than ACL. Free trial
avaliable.
For a more cross-lisp portable approach, there's always CLIM, the Common Lisp
Interface Manager, with implementations for ACL, Lispworks, Macintosh CL and
others. A free version is in the works, right now it runs on CMUCL, SBCL and
OpenMCL (well, to be honest it walks more than it runs).
CLIM is a really cool API, very lispy, but the implementations tend to lack
somehow in the eye candy department.
Windows likeness is usability - at least for users just switching
from Windows to Unix. Just like having sloppy focus is a usability feature
for a lot of long-time Unix users.
IMHO, your post shows one of the fundamental misassumptions of lots of
usability folk: There is no one way to build a usable system, because users
come from very different backgrounds. Of course, neither Windows not older
Unix interfaces nor the Mac or BeOS are the perfect interface, but whatever
cool solution you come up with, there better be a nice transition path for
people that already know how to work with other systems. This is unfortunatly
very hard.
FreeBSDs decision to move Perl from the base system to the ports tree was
because it was easier to handle that way, both for developers and users. It
was not about not supporting it anymore. In fact, it is supported quite well,
including automatic integration of CPAN packages with the package management
utils etc.
This seems to be easily misunderstood, probably especially by Linux users
where no distinction between base system and third-party apps exists (or
in a less visible way, at least).
It did indeed mean that some tools in the base had to be reimplemented, either
in C or as shell scripts. Obviously the majority of developers decided that
this was less pain than having to keep one version of perl around even when
users want a newer one, because you could break their systems otherwise, to
have to check various important parts of the systems when you integrate an
updated perl etc.
The result of all this is that having an up-to-date perl is just one
"portinstall perl" away, the system is more stable and modular, and, indeed,
that trivial
perl utilities like those in the article are unlikely to become base components.
Big deal.
Bullshit. It is highly unlikely that his tools would be included in the base system, and all *BSDs come with lots of GPLed third party apps in the ports/pkgsrc.
If you want to get code in the base system, it would be a good idea to adopt a more liberal license, or become as important as GCC.
"Donating" the code back to the FSF? They pretty much have to release it under a GPL-compatible license anyway, if they don't plan to keep their improvements inhouse.
Apple (or probably rather NeXT, but who cares nowadays) already tried once to improve GCC without releasing their changes, esp. the Objective C support. Turned out not to be such a good idea.
By switching to Linux for operating system, Munich avoids depending on Microsoft for technical support and product upgrades.
In other words, they still run their legacy environment, only in a more complex setup and without technical support and product upgrades from Microsoft.
The only winner in this deal seems to be VMWare. That's fine for me, they made a kick-ass product, but somehow I don't get why the guys in Munich chose to pay license fees to them and SuSE without solving the real problem at hand.
Let's see: Instead of desktops running a closed OS they now run a closed OS in a closed virtualization environment on a free OS. Yep. Way more control. I bet every admin will be amazed about that setup.
Donald Knuth wrote, about TeX, that a programmer should also do QA, use the program, and write the manual.
He also said that hard programs can only be written by a single programmer. This is just not an option in a world where you can't just take 10 years off to write TeX because the look of your books isn't satisfying. Most people just aren't Don Knuth - they are neither geniuses nor professors for the Art of Computer Programming.
Slashdot Mirror
Kiddie-Porn wasn't ever legal, of course. The existing loopholes are of the kind that cannot be fixed legislatively by a single country (or the EU, for that matter).
It is really simple: When a user wants to see something, he issues a GET. This is idempotent and doesn't carry any kind of state except what the client explicitly provides, like the URI, the preferred format and language, and his credentials. If he wants to perfom some destructive operation, he uses POST, PUT or DELETE. Again, all that's neccessary for the server to know is in the headers and the payload, where applicable.
Listen, web developers: Using HTTP the way it was meant to actually works. You don't need kludges like cookies or GET with lots of parameters where what you do has nothing to do with GETting a resource. It even makes lots of nasty problems go away, like the back-button breaking your app. Try reading and understanding the actual specs, or the diss of the guy who wrote (some of) them.
No, but unlike qmail, it is Free Software.
Dont programm in C unless you have a really good reason to.
Good reasons are:
- You are extending an operating system kernel or other huge system that is written in C.
- You are writing a library and expect it to be used from several other languages. C is the lowest common denominator, every language has a C interface.
In all other cases, use a high-level language. Users and admins will be grateful for not having to download patched versions every time a buffer overflow or format-string error is found. You will like being able to concentrate on the core problem you want to solve instead of dealing with all the detail C and its libraries left for you to care about. If you need speed, use a high-level language with a good compiler. If you need to bit-fiddling, use a high-level language with good bit-fiddling support. They exist, and there's even some overlap between them.I for one don't think that a free Windows version would kill Trolltech. The people using Qt/Win right now are unlikely to use it, and most will probably simply still paying for the commercial license.
Wouldn't some kind of executable or shared module be helpfull?
So use Epiphany or Galeon, if you don't mind Gnome. Or maybe Skipstone, if that is still alive. Even Firebird is supposed to be snappier, even if I could not see much improvement myself.
Frankly, I guess the language is still rather shitty. Problem is, it is there, and lots of apps use it, especially custom in-house stuff. Somebody in Munich will probably perform a Schuhplattler out of joy when he hears about that.
Right. Just like Windows XP Pro is only $299 if your time has no value. Your point?
It might be an OK replacement for Emacs-as-an-IDE, but Emacs is more. It is more compareble to KDE or Gnome plus a lot of third-party apps and real pervasive interoperability, and while there is probably not much making it impossible to extend Eclipse in that direction (except the no-window-system part probably), nobody has done it yet. Wake me up again when this has changed.
For a more cross-lisp portable approach, there's always CLIM, the Common Lisp Interface Manager, with implementations for ACL, Lispworks, Macintosh CL and others. A free version is in the works, right now it runs on CMUCL, SBCL and OpenMCL (well, to be honest it walks more than it runs). CLIM is a really cool API, very lispy, but the implementations tend to lack somehow in the eye candy department.
IMHO, your post shows one of the fundamental misassumptions of lots of usability folk: There is no one way to build a usable system, because users come from very different backgrounds. Of course, neither Windows not older Unix interfaces nor the Mac or BeOS are the perfect interface, but whatever cool solution you come up with, there better be a nice transition path for people that already know how to work with other systems. This is unfortunatly very hard.
This seems to be easily misunderstood, probably especially by Linux users where no distinction between base system and third-party apps exists (or in a less visible way, at least).
It did indeed mean that some tools in the base had to be reimplemented, either in C or as shell scripts. Obviously the majority of developers decided that this was less pain than having to keep one version of perl around even when users want a newer one, because you could break their systems otherwise, to have to check various important parts of the systems when you integrate an updated perl etc. The result of all this is that having an up-to-date perl is just one "portinstall perl" away, the system is more stable and modular, and, indeed, that trivial perl utilities like those in the article are unlikely to become base components. Big deal.system, and all *BSDs come with lots of GPLed third party apps in the
ports/pkgsrc.
If you want to get code in the base system, it would be a good idea to adopt
a more liberal license, or become as important as GCC.
For some reason, I doubt that Dev-C++, "a full-featured IDE for Win32" would be a good alternative when you are looking for a cross-platform Ada IDE.
Apple (or probably rather NeXT, but who cares nowadays) already tried once to improve GCC without releasing their changes, esp. the Objective C support. Turned out not to be such a good idea.
The only winner in this deal seems to be VMWare. That's fine for me, they made a kick-ass product, but somehow I don't get why the guys in Munich chose to pay license fees to them and SuSE without solving the real problem at hand.
Let's see: Instead of desktops running a closed OS they now run a closed OS in a closed virtualization environment on a free OS. Yep. Way more control. I bet every admin will be amazed about that setup.
Note also that RealNetworks just open-sourced their SMIL implementation. Maybe that could speed up adoption, at least for open source browsers.