i actually like lynx better than links (and use it for most of my article reading, including/.), because it *doesn't* support tables.
when you're reading a text article in a terminal window, you (well, at least *I*) don't want navigation bars at the left or right. i want a full screen of text. lynx, by turning <tr> into linebreaks and <td> into space, lets you browse like this: skip the first few pages of nav junk with a few spacebar hits, and then read the article without anything else cluttering the window.
This works well, but current mozilla has a better option: in the preferences window, go to "privacy & security", select "cookies", click on "limit maximum lifetime of cookies to", and select "current session".
This works with all sites, and forbids them from saving permanent info on your hard disk (i.e tracking you across sessions).
Re:Issues with the euro in day-to-day life
on
The Euro
·
· Score: 2
another spaniard here... and i totally agree with your last point: where is the 25 cent coin?? i won't miss the peseta (or the french franc, or any other dead currency), but i really think 25c is a better mount than 20c for a coin.
another gripe: the euro's set of coins is way too granular. there are coins of 1, 2, 5, 10, 20, 50, 100 and 200 cents. for the same range, they could have just had 1, 5, 25, 100, 200; it's easy enough to handle arbitrary amounts, and it would have simplified everyone's life by remembering only 5 coins instead of 8.
speak for yourself. I've met plenty of computer programmer types who enjoyed socializing, and guess what, I'm one of those too. my main way of functioning is still introverted (as in, i need my time alone, i like to collect my thoughts on my own, and i like people one by one more better than in large groups), but i sure get a lot of mental energy from hanging out w/ friends. of the people from work, i usually end up hanging out w/ non-techies for the most part.
free software kind of people are often averse to paying for software for their own use (quite understandably so: there's a plethora of free software that does a good job at all kinds of jobs out there), but we're not averse to trying things. and getting programmers to be familiar with kylix is most definitely in borland's interest. if i download kylix-free-as-in-beer, play with it a bit, and am impressed with it, maybe at some point later i'll recommend it for some serious development work (where the bills would be paid by a company, so the free software developper's averseness to paying for software doesn't apply).
... puts the window name (from an env variable set at.xinitrc time), the machine name and the current dir at the window title, and prints a plain '$ ' as the prompt, or '# ' if i'm root. it also clears any bold mode or color, in case the previous program forgot to do so.
part of the problem with this is that more and more of the work of putting a cohesive whole together out of GNU/Linux, GNOME, KDE and other big projects, is being done by the distributors. Even the kernel itself is going that way; a typical RedHat or Mandrake kernel has dozens if not hundreds of patches over the regular Linus kernel, and is (at least in theory) better tested, balanced and tuned. With desktop environments, same deal: they're a pain to put together between all the libraries, CVS versions, snapshots, and so on, that it's hard to get them to work from source, and regular people are just grabbing whatever some distributor (RH or Ximian or whoever) packaged up for them. This is part of a trend towards complexity that I'm not all that happy about.
I like the Unix idea of programs that do things (complicated or simple) in a fairly standalone way, with well-defined interfaces, and that can be replaced, recompiled and debugged fairly easily.
unfortunately, all these componentized architectures that desktop environments use seem to be going in the opposite direction: everything depending on everything, hugely complicated APIs all over the place, and virtual DLL hell.
this sounds like a losing situation to me. the good thing about it is that the unix underpinnings of the system are still there, and I can skip GNOME and KDE and their associated heaps of GUIish programs if I don't like them. but you can't really skip using a web browser at this point in time, and the current web specs are so overcomplicated that there's no chance of anyone doing a browser whose source can actually be undesrtood and debugged by mere mortals.
no, we should teach them to ignore it, by dismissing it as something not even worth spending a second of brain-CPU on, as naturally as possible. if you don't expose children to advertising at all, they won't know how to cope with it, and they'll fall for it much more when they eventually grow up and see it.
I like Banks' stuff, and I was very impressed with the other non-sci-fi book of his that I read: The Bridge. It's a surreal story of a guy who finds himself in a huge bridge-like sturcture, and goes around trying to figure out what it's all about. very good and surprising ending, too.
now this, I don't know about you, but businesses are pretty damn near the bottom of my list of things that I want to read about in my spare time. sorry, just not interested. if I want to read about business practices and organizations, workplace power struggles, etc, there are enough of them in the real world that I don't need fiction about them. but thanks anyway:)
He's just talking about the defaults; you can always put 'no strict;' after your module or class declaration.
All in all, this first introduction to LW's ideas for perl6 sounds pretty good. I'm looking forward to more details about what he plans to do with references. Blurring the difference between an array and an arrayref, as he proposes, seems like it could be either the biggest fuckup, or the biggest improvement to the perl language. I can't wait to read the proposed new semantics and see how it's going to work.
This probably goes together with giving prototypes and typed arguments to functions and methods; I wonder if perl6 is going to need an 'apply' function, to pass a list of arguments to a function (as opposed to passing the list as a single argument), like Python does. As a perl programmer, at first it sounds bad to me, but I could possibly be convinced that it's worth it.
Finally, I'm a bit skeptical about the idea of compiling perl into jvm or C#/IL. Despite all claims to the contrary, I don't see these bytecodes being generic enough to implement all of perl's functions (including its amazingly extended regexp engine) with reasonable efficiency. The OO side (integrating objects and mapping methods and properties) isn't really the problem, but I just don't see a JVM-compiled perl module using C-based extensions from CPAN, and I don't see all CPAN modules giving up C integration either. All in all, I think the perl interpreter should remain C, with a good C-based extension model (more like SWIG, and losing the "XS" obfuscated lossage), and work together with the JVM and IL interpreters, supplementing them at the C level to run perl code.
1)/. is coded in mod_perl, with precompilation of scripts and all, so it's not all that inefficient. 2) Apache/mod_perl code is very portable between Unix systems; unless you go out of your way to use odd non-portable things like syscall(), the odds are that your Linux code will run on FreeBSD without a single change
3) the source code of/. is opensource (see slashcode.com, and has quite a following. I'm sure it's been tested on many OSs beyond Linux and FreeBSD.
I'm sorry, but those 7 lines of perl, even as cryptic as they are, sure look a lot simpler to me than the usual DeCSS.c code that's been floating around the net. Whoever wrote the perl code must have done a great job finding the logic behind those tables of numbers. I'm sure that you could turn this perl code back into readable C, and it would be much clearer than the original DeCSS.c. What's more, it'd probably be easier to do it starting from this perl code, than starting with the C code and redoing the work of analyzing the integer tables.
yep, it can be done in theory. in practice, most web developpers are way to clueless to put public key crypto in their webserver backends. even initiating a client SSL connection from the merchant's webserver is documented as "hard, not recommended for most users" by the gateways that offer this kind of secure options, imagine doing raw crypto by encrypting things with a key and sending them....
btw, encrypting things with your public key amounts to a digital signature, so why not do that instead? send the data, and include a signature with it.
The thing here is that any payment gateway worth it's salt (Like
Authorize.net or iTransact.com) will return, along with a status code
about the transaction, a field containing the amount the buyers card
was debited for, so they can then compare it to their records and see
of the correct price was paid.
If you're doing it the cheap & easy way, by having your shopping cart software POST to the authorize.net (or whoever) gateway, and then getting the status back as a redirection from the user, you're *still* screwed, even if you check the return code. Anything that goes through a redirection on the user's side can be altered by the user.
Speaking of authorize.net, take a look at this page; it includes an example of HTML code used to link to their service, and *of course*, it has the price changing flaw. Even funnier, if you run their Test Drive, you get not one, but TWO occasions to save the form to a local HTML file, edit the price value, submit it back, and their system is very happy to take your order at the price you've given.
So, in short, if 30% of e-commerce sites out there have this problem (as the yahoo article claims), it's not just because of bad programming on the site's side, but also because of gateway services offering and advertising services that are insecure by design. I really wonder if a site that has lost money because of this couldn't sue them for it.
it's not just the technical work that's good... it also shows once again that Linux has come of age. a new OS can get a jumpstart by emulating others, but it's when others start emulating it that you can say it's really made it.
Not really... the 2.2 branch hasn't even reached 2.2.20 yet, and it's been really stable for a while. basically, among "stable" (even middle number) kernels, you have to go by reputation (or do some heavy testing yourself, if you have the time and resources). there have been cases where a stable revision (within the 2.2 branch, or earlier within the 2.0 one) was worse than the previous one. in the 2.2 branch, 2.2.5 was already quite stable. my feeling with 2.4 is that it has been handled better than 2.2; I wouldn't be surprised to see something like 2.4.2 shipped by major distributions and widely deployed.
Yes. Mailbox just sucks for POP3 and IMAP; the server has to lock the file, copy it, and rewrite the entire damn thing, just to delete a message or stick a flag in one. It's just painful to see the amount of work an IMAP or POP3 server has to do when handling one of these obscene 30MB mboxes with lots of word attachments.
What I do is configure maildirs for everyone on the mail server, using either qmail or postfix (both can deliver to maildir; qmail is more minimalistic but a bit confusing, postfix is about as good and a lot more understandable), and then setup qmail's pop3 daemon (even if using postfix to deliver). This combination has worked so well for me that I use it both on server and on my desktop computer (getting mail from pop3 with fetchmail, delivering into maildirs, reading with mutt).
The only thing to make sure with maildir is that you have enough inodes. But that's easy to handle when formatting the partition, and (even better) you could use reiserfs, which has dynamic inode allocation and handles large directories of small files very well.
This is either a troll or a case of bad misinformation. Odd version numbers are development (unstable), but that's the middle number, not the final one. so 2.4.1 is stable, because 4 is even. the 2.5 series will open in a few months time, and will eventually lead up to 2.6 or 3.0 or whatever the next stable branch is called.
hmmm? tucows owns Linux Weekly News (LWN.net), which is a great Linux site to keep up to date with everything that's going on around Linux. And LWN alone has at least 3 or 4 people writing on it, full-time, about Linux news. I have no idea what Tucows' Linux "channel" is like, but I don't see any reason to bash their Linux news -- LWN is doing a truly great job.
MySQL have for many years been been considered as a very unstable
product and that it have been (still are probably) lacking a lot of
really useful features.
No, MySQL has been rock stable at the very least for the last 2 years. I've been using it for website development since mid 98 or thereabouts, and it's never crashed or lost any data. MySQL is definitely nowhere near the high end of databases when it comes to features, but what it does, it does it really well.
last I took a Montpellier-Barcelona train myself (I live in Barcelona btw), it stopped in a tunnel near at the border for 15 minutes, while mechanic noises were heard. so apparently these trains are equiped to work on different widths, somehow. anyway, i'm pretty sure that Spain's railroad width is not the same as the rest of Europe's, because whenever they speak about building high speed trains (like the French TGV) in Spain, they stress that these run on standard european width rails.
Slashdot Mirror
when you're reading a text article in a terminal window, you (well, at least *I*) don't want navigation bars at the left or right. i want a full screen of text. lynx, by turning <tr> into linebreaks and <td> into space, lets you browse like this: skip the first few pages of nav junk with a few spacebar hits, and then read the article without anything else cluttering the window.
This works with all sites, and forbids them from saving permanent info on your hard disk (i.e tracking you across sessions).
another spaniard here... and i totally agree with your last point: where is the 25 cent coin?? i won't miss the peseta (or the french franc, or any other dead currency), but i really think 25c is a better mount than 20c for a coin. another gripe: the euro's set of coins is way too granular. there are coins of 1, 2, 5, 10, 20, 50, 100 and 200 cents. for the same range, they could have just had 1, 5, 25, 100, 200; it's easy enough to handle arbitrary amounts, and it would have simplified everyone's life by remembering only 5 coins instead of 8.
speak for yourself. I've met plenty of computer programmer types who enjoyed socializing, and guess what, I'm one of those too. my main way of functioning is still introverted (as in, i need my time alone, i like to collect my thoughts on my own, and i like people one by one more better than in large groups), but i sure get a lot of mental energy from hanging out w/ friends. of the people from work, i usually end up hanging out w/ non-techies for the most part.
lwn.net/daily should be a good replacement. they carry fewer links, but very well chosen.
free software kind of people are often averse to paying for software for their own use (quite understandably so: there's a plethora of free software that does a good job at all kinds of jobs out there), but we're not averse to trying things. and getting programmers to be familiar with kylix is most definitely in borland's interest. if i download kylix-free-as-in-beer, play with it a bit, and am impressed with it, maybe at some point later i'll recommend it for some serious development work (where the bills would be paid by a company, so the free software developper's averseness to paying for software doesn't apply).
PS1=$'%{\e[m\e]2; ['"$WINTITLE"$'] %m - %~ \a\e[m%}%(#.#.$) '
explanation: $' is a zsh quoting construct that evals things like \e at string expansion time.
I like the Unix idea of programs that do things (complicated or simple) in a fairly standalone way, with well-defined interfaces, and that can be replaced, recompiled and debugged fairly easily.
unfortunately, all these componentized architectures that desktop environments use seem to be going in the opposite direction: everything depending on everything, hugely complicated APIs all over the place, and virtual DLL hell.
this sounds like a losing situation to me. the good thing about it is that the unix underpinnings of the system are still there, and I can skip GNOME and KDE and their associated heaps of GUIish programs if I don't like them. but you can't really skip using a web browser at this point in time, and the current web specs are so overcomplicated that there's no chance of anyone doing a browser whose source can actually be undesrtood and debugged by mere mortals.
no, we should teach them to ignore it, by dismissing it as something not even worth spending a second of brain-CPU on, as naturally as possible. if you don't expose children to advertising at all, they won't know how to cope with it, and they'll fall for it much more when they eventually grow up and see it.
now this, I don't know about you, but businesses are pretty damn near the bottom of my list of things that I want to read about in my spare time. sorry, just not interested. if I want to read about business practices and organizations, workplace power struggles, etc, there are enough of them in the real world that I don't need fiction about them. but thanks anyway :)
All in all, this first introduction to LW's ideas for perl6 sounds pretty good. I'm looking forward to more details about what he plans to do with references. Blurring the difference between an array and an arrayref, as he proposes, seems like it could be either the biggest fuckup, or the biggest improvement to the perl language. I can't wait to read the proposed new semantics and see how it's going to work.
This probably goes together with giving prototypes and typed arguments to functions and methods; I wonder if perl6 is going to need an 'apply' function, to pass a list of arguments to a function (as opposed to passing the list as a single argument), like Python does. As a perl programmer, at first it sounds bad to me, but I could possibly be convinced that it's worth it.
Finally, I'm a bit skeptical about the idea of compiling perl into jvm or C#/IL. Despite all claims to the contrary, I don't see these bytecodes being generic enough to implement all of perl's functions (including its amazingly extended regexp engine) with reasonable efficiency. The OO side (integrating objects and mapping methods and properties) isn't really the problem, but I just don't see a JVM-compiled perl module using C-based extensions from CPAN, and I don't see all CPAN modules giving up C integration either. All in all, I think the perl interpreter should remain C, with a good C-based extension model (more like SWIG, and losing the "XS" obfuscated lossage), and work together with the JVM and IL interpreters, supplementing them at the C level to run perl code.
1) /. is coded in mod_perl, with precompilation of scripts and all, so it's not all that inefficient. /. is opensource (see slashcode.com, and has quite a following. I'm sure it's been tested on many OSs beyond Linux and FreeBSD.
2) Apache/mod_perl code is very portable between Unix systems; unless you go out of your way to use odd non-portable things like syscall(), the odds are that your Linux code will run on FreeBSD without a single change
3) the source code of
what are the offending MIME types, so people can block them at the mail server?
I'm sorry, but those 7 lines of perl, even as cryptic as they are, sure look a lot simpler to me than the usual DeCSS.c code that's been floating around the net. Whoever wrote the perl code must have done a great job finding the logic behind those tables of numbers. I'm sure that you could turn this perl code back into readable C, and it would be much clearer than the original DeCSS.c. What's more, it'd probably be easier to do it starting from this perl code, than starting with the C code and redoing the work of analyzing the integer tables.
slashdot, for the command line at the end of the example.
btw, encrypting things with your public key amounts to a digital signature, so why not do that instead? send the data, and include a signature with it.
If you're doing it the cheap & easy way, by having your shopping cart software POST to the authorize.net (or whoever) gateway, and then getting the status back as a redirection from the user, you're *still* screwed, even if you check the return code. Anything that goes through a redirection on the user's side can be altered by the user.
Speaking of authorize.net, take a look at this page; it includes an example of HTML code used to link to their service, and *of course*, it has the price changing flaw. Even funnier, if you run their Test Drive, you get not one, but TWO occasions to save the form to a local HTML file, edit the price value, submit it back, and their system is very happy to take your order at the price you've given.
So, in short, if 30% of e-commerce sites out there have this problem (as the yahoo article claims), it's not just because of bad programming on the site's side, but also because of gateway services offering and advertising services that are insecure by design. I really wonder if a site that has lost money because of this couldn't sue them for it.
it's not just the technical work that's good... it also shows once again that Linux has come of age. a new OS can get a jumpstart by emulating others, but it's when others start emulating it that you can say it's really made it.
I use something like this very often: scp box:`pwd`/files\* .
Not really... the 2.2 branch hasn't even reached 2.2.20 yet, and it's been really stable for a while. basically, among "stable" (even middle number) kernels, you have to go by reputation (or do some heavy testing yourself, if you have the time and resources). there have been cases where a stable revision (within the 2.2 branch, or earlier within the 2.0 one) was worse than the previous one. in the 2.2 branch, 2.2.5 was already quite stable. my feeling with 2.4 is that it has been handled better than 2.2; I wouldn't be surprised to see something like 2.4.2 shipped by major distributions and widely deployed.
What I do is configure maildirs for everyone on the mail server, using either qmail or postfix (both can deliver to maildir; qmail is more minimalistic but a bit confusing, postfix is about as good and a lot more understandable), and then setup qmail's pop3 daemon (even if using postfix to deliver). This combination has worked so well for me that I use it both on server and on my desktop computer (getting mail from pop3 with fetchmail, delivering into maildirs, reading with mutt).
The only thing to make sure with maildir is that you have enough inodes. But that's easy to handle when formatting the partition, and (even better) you could use reiserfs, which has dynamic inode allocation and handles large directories of small files very well.
This is either a troll or a case of bad misinformation. Odd version numbers are development (unstable), but that's the middle number, not the final one. so 2.4.1 is stable, because 4 is even. the 2.5 series will open in a few months time, and will eventually lead up to 2.6 or 3.0 or whatever the next stable branch is called.
hmmm? tucows owns Linux Weekly News (LWN.net), which is a great Linux site to keep up to date with everything that's going on around Linux. And LWN alone has at least 3 or 4 people writing on it, full-time, about Linux news. I have no idea what Tucows' Linux "channel" is like, but I don't see any reason to bash their Linux news -- LWN is doing a truly great job.
last I took a Montpellier-Barcelona train myself (I live in Barcelona btw), it stopped in a tunnel near at the border for 15 minutes, while mechanic noises were heard. so apparently these trains are equiped to work on different widths, somehow. anyway, i'm pretty sure that Spain's railroad width is not the same as the rest of Europe's, because whenever they speak about building high speed trains (like the French TGV) in Spain, they stress that these run on standard european width rails.