Who said anything about the running speed? Didn't I just discredit that? The point was that a programmer knowledgable in Perl, Python, and Java would most certainly implement the program very quickly in Perl or Python.
Perl's speed actually surprises many, but speed isn't everything that should be considered in a language. The bet between Guido and Dan was on a completely academic level, not a pubescent drag race. =)
Quick, get me a Java app that scans a set of maildir directories and outputs all messages by "TmdrCaco" to STDOUT in mbox format!
That's about what I was thinking, it looks like it's more oriented towards embedded databases, rather than client-server ones. Maybe the OP has heard of Microsoft's Jet database engine used with VB or FoxPro? A very nice combo for storing a small data set in a regular fashion. SQLite is very handy also, in the open-source world. Actually, isn't SQLite in the public domain? Good stuff.
I think it may be possible to use MySQL for a heavier embedded database... hence the dual-licensing, in case your company embeds MySQL, but doesn't want to GPL their product.
Yes, it's an administered restriction. Google configured GMail's MTAs it to limit messages to 10MB, which is effectively 7.5MB for a message with an attachment. (You can, OTOH, send someone a 10MB email message consisting only of text. I don't know if GMail checks to see if the attachment is 8-bit or not, so you may be able to attach a 10MB text file, or it could B64 it regardless) Base64 itself has no such limitation, it's simply a different way to express data, which is only limited by the hardware available and the technique used to encode/decode the data.
How Base64 Encoding Works - Here's a good document about Base64 encoding itself, and how it works in conjunction with MIME for use in email.
It doesn't mention that MIME has a header field that specifies encoding (Content-Encoding) and that Base64 is one choice in a handful of possible encodings to use. Base64 is probably your best bet for getting an attachment to its destination today, even though it grows the data (byte-wise) by 33% for transport.
I know what you mean; I never even liked The Screen Savers! For a while, about 350 TotalFark members were running a Music Ring, where everyone was required to use a GMail account. We moved about 500-600 MB of mail into 350 mailboxes each day. I never saw a hiccup speed-wise when downloading attachments, that is, whatever connection I was on would max out. We did run against some GMail-imposed limitations that are intended to control load: First, outgoing messages are limited to 100 recipients, beyond that point, they are silently removed. Second, GMail limits a single client to a handful (3 or 4) of simultaneous connections at a time. (For example, if you have 3 or 4 attachment downloads running, any new connections will block until another connection closes or the timeout is reached.) Third, and this is actually documented, but not well, GMail limits single messages to 10MB in size. What they don't explain, and what I had to explain repeatedly, is that you actually have a limit for attachments of 7.5MB, because of Base64 encoding for MIME.
Not too shabby, but I still wonder why they paid to use this software instead of OOo... They are missing out on the other platforms here.
BTW, it's written in Visual Basic. Flame on!;)
I don't even know what you're talking about-- slackware has had easy removal of packages nearly forever! Incredibly, it's called 'removepkg', but like any tool, you can shoot yourself in the foot if you're not careful. =) With the addition of Swaret to the mix, managing packages on slackware is too easy.
Nice to see a monk out here in the wilds! BTW, chromatic, did you look at the code for the Perl tests on the article? They're a little... weird. It looks like his shell took a pass at interpolating the command line before he pasted it into the page, or something.
I suppose the fact that he includes "perl -le " at the start of so many "tests" isn't really fair either -- most of those interpreters support similar one-liner options, but they got away with just the program code.:\
It's not "some flash movie" check it out, you can load up Breakout, Pong, MacDraw, and more. You can browse folders too. This is some cool work, I'd love to see the code for doing the system so flexibly in flash.
I'm glad to see more alternative languages for the.NET/Mono platform... If we're gonna get stuck with it, we may as well make the best of it!:) Seeing Python run nice and fast, being a dynamic language and on a VM, is great stuff too.
One correction here: qemu-fast doesn't require a kernel module, but it does require a change to a kernel constant. Basically, you have to adjust the kernel so it expects to be loaded to a different location in memory when it starts. Another neat feature of Qemu is that you can point it at a linux kernel file, and it will load it at the right place in (emulated) memory, then begin executing, thus skipping the emulated PC BIOS.
One thing not to forget is that Qemu wants to be a portable project and emulate a few different platforms. They're just beginning to add optimizations to IA-32/x86 emulation, and they have added a few x86-on-x86 tweaks already.
I just can't handle playing without my keyboard and mouse! Sure, you can plug 'em into the XBox, but who wants to pay MS for an old PC painted black anyway?;)
I hope Doom 3 has some good gameplay and isn't just a pixelfest -- Everyone trying to make the prettiest game is really getting old.
It's great to see you personally responding to this, Jim. I love the way that the installer displays banners giving credit for so many of the projects packaged in WBL. I don't see any pirating going on here -- everyone's abiding by the rules provided by the original author in their distribution license. There's a term used around slashdot, "Don't feed the trolls", but I understand your desire to make a personal comment here.:)
If your OpenLDAP/Kerb5 kit was put together right, you could use the LDAPv3 setup for authenticating more standard clients, and use pGINA for Windows. It won't kerberize you (yet), but SSL should provide your basic security. Samba servers using the LDAP backend should fit quite nicely.
Another idea is to configure LDAPv3, and set up a Samba server(with the LDAP backend) as a Domain Logon server. If these are all on one server, you've pretty much built the same thing Microsoft does on an AD PDC, but without the tight integration. LDAP clients get the full benefit, and Windows clients will work out of the box. Think of it like half-assed AD.:)
What would be nice is to see something like Apache Toolbox for OpenLDAP and Kerberos. LDAPv3 is quite a task to get set up, and I think the huge learning curve for the system is it's largest flaw. Seriously, Microsoft only needs to know your dns domain to get everything configured, why can't it be that easy?:>
Bah! Users will never figure out that 'rm' will very much eat their files. Personally, though, I find a misplaced shell redirect '> pron.txt' (Crap, I meant to overwrite plan.txt!) is even more trouble than that. Insta-wipe with no left-over data on the disk.
I'd recommend looking into libtrash. Very handy, saves stretch on your tapes -- we are keeping regular backups, right?
Another good tip that gets me sometimes is, when you use the paste buffer (explicit Ctrl-C), the originating program has to still be running to make the paste.
If you're not forced to do so, change it to sftp://. It is a much better solution if your ssh target has an sftp backend. FISH uses basic shell tools at the remote, like shfs, and that's just too much complexity to be a good solution.
Slashdot Mirror
You're right. Don't trust the MD5 from anyone but Microsoft.
One marketing-case word: AuthentiCode. The executable is probably self-signed. Check the properties of the file.
Wha? What?
Who said anything about the running speed? Didn't I just discredit that? The point was that a programmer knowledgable in Perl, Python, and Java would most certainly implement the program very quickly in Perl or Python.
Perl's speed actually surprises many, but speed isn't everything that should be considered in a language. The bet between Guido and Dan was on a completely academic level, not a pubescent drag race. =) Quick, get me a Java app that scans a set of maildir directories and outputs all messages by "TmdrCaco" to STDOUT in mbox format!
(Holy crap, I'm aggreeing with an AC)
That's about what I was thinking, it looks like it's more oriented towards embedded databases, rather than client-server ones. Maybe the OP has heard of Microsoft's Jet database engine used with VB or FoxPro? A very nice combo for storing a small data set in a regular fashion. SQLite is very handy also, in the open-source world. Actually, isn't SQLite in the public domain? Good stuff.
I think it may be possible to use MySQL for a heavier embedded database... hence the dual-licensing, in case your company embeds MySQL, but doesn't want to GPL their product.
Yes, it's an administered restriction. Google configured GMail's MTAs it to limit messages to 10MB, which is effectively 7.5MB for a message with an attachment. (You can, OTOH, send someone a 10MB email message consisting only of text. I don't know if GMail checks to see if the attachment is 8-bit or not, so you may be able to attach a 10MB text file, or it could B64 it regardless) Base64 itself has no such limitation, it's simply a different way to express data, which is only limited by the hardware available and the technique used to encode/decode the data.
How Base64 Encoding Works - Here's a good document about Base64 encoding itself, and how it works in conjunction with MIME for use in email.
It doesn't mention that MIME has a header field that specifies encoding (Content-Encoding) and that Base64 is one choice in a handful of possible encodings to use. Base64 is probably your best bet for getting an attachment to its destination today, even though it grows the data (byte-wise) by 33% for transport.
I know what you mean; I never even liked The Screen Savers! For a while, about 350 TotalFark members were running a Music Ring, where everyone was required to use a GMail account. We moved about 500-600 MB of mail into 350 mailboxes each day. I never saw a hiccup speed-wise when downloading attachments, that is, whatever connection I was on would max out. We did run against some GMail-imposed limitations that are intended to control load: First, outgoing messages are limited to 100 recipients, beyond that point, they are silently removed. Second, GMail limits a single client to a handful (3 or 4) of simultaneous connections at a time. (For example, if you have 3 or 4 attachment downloads running, any new connections will block until another connection closes or the timeout is reached.) Third, and this is actually documented, but not well, GMail limits single messages to 10MB in size. What they don't explain, and what I had to explain repeatedly, is that you actually have a limit for attachments of 7.5MB, because of Base64 encoding for MIME.
Oh well, this is Slashdot; what do you expect? =)
Not too shabby, but I still wonder why they paid to use this software instead of OOo... They are missing out on the other platforms here. BTW, it's written in Visual Basic. Flame on! ;)
Have you tried the fairly-similar Googlebar? It runs on Mozilla and FireFox.
I don't even know what you're talking about-- slackware has had easy removal of packages nearly forever! Incredibly, it's called 'removepkg', but like any tool, you can shoot yourself in the foot if you're not careful. =) With the addition of Swaret to the mix, managing packages on slackware is too easy.
If you want PAM, you can roll your own and make packages of it, or you can use the PAM packages from Dropline GNOME. I still don't recommend it! =)
Nice to see a monk out here in the wilds! BTW, chromatic, did you look at the code for the Perl tests on the article? They're a little... weird. It looks like his shell took a pass at interpolating the command line before he pasted it into the page, or something.
:\
I suppose the fact that he includes "perl -le " at the start of so many "tests" isn't really fair either -- most of those interpreters support similar one-liner options, but they got away with just the program code.
Also see UltraVNC. They're making great strides in VNC performance. :)
hehe
http://www.samba.org 'nuff said.
It's not "some flash movie" check it out, you can load up Breakout, Pong, MacDraw, and more. You can browse folders too. This is some cool work, I'd love to see the code for doing the system so flexibly in flash.
I'm glad to see more alternative languages for the .NET/Mono platform... If we're gonna get stuck with it, we may as well make the best of it! :) Seeing Python run nice and fast, being a dynamic language and on a VM, is great stuff too.
but I didn't get that punchline. Someone care to fill me in?
;)
I just think they should make laws that allow citizens to murder and/or seriously injure known spammers.
Konqueror allows users to save a page and it's dependencies in a Web ARchive. It's pretty much a .tgz file renamed.
One correction here: qemu-fast doesn't require a kernel module, but it does require a change to a kernel constant. Basically, you have to adjust the kernel so it expects to be loaded to a different location in memory when it starts. Another neat feature of Qemu is that you can point it at a linux kernel file, and it will load it at the right place in (emulated) memory, then begin executing, thus skipping the emulated PC BIOS.
One thing not to forget is that Qemu wants to be a portable project and emulate a few different platforms. They're just beginning to add optimizations to IA-32/x86 emulation, and they have added a few x86-on-x86 tweaks already.
I just can't handle playing without my keyboard and mouse! Sure, you can plug 'em into the XBox, but who wants to pay MS for an old PC painted black anyway? ;)
I hope Doom 3 has some good gameplay and isn't just a pixelfest -- Everyone trying to make the prettiest game is really getting old.
It's great to see you personally responding to this, Jim. I love the way that the installer displays banners giving credit for so many of the projects packaged in WBL. I don't see any pirating going on here -- everyone's abiding by the rules provided by the original author in their distribution license. There's a term used around slashdot, "Don't feed the trolls", but I understand your desire to make a personal comment here. :)
If your OpenLDAP/Kerb5 kit was put together right, you could use the LDAPv3 setup for authenticating more standard clients, and use pGINA for Windows. It won't kerberize you (yet), but SSL should provide your basic security. Samba servers using the LDAP backend should fit quite nicely.
Another idea is to configure LDAPv3, and set up a Samba server(with the LDAP backend) as a Domain Logon server. If these are all on one server, you've pretty much built the same thing Microsoft does on an AD PDC, but without the tight integration. LDAP clients get the full benefit, and Windows clients will work out of the box. Think of it like half-assed AD. :)
What would be nice is to see something like Apache Toolbox for OpenLDAP and Kerberos. LDAPv3 is quite a task to get set up, and I think the huge learning curve for the system is it's largest flaw. Seriously, Microsoft only needs to know your dns domain to get everything configured, why can't it be that easy? :>
Bah! Users will never figure out that 'rm' will very much eat their files. Personally, though, I find a misplaced shell redirect '> pron.txt' (Crap, I meant to overwrite plan.txt!) is even more trouble than that. Insta-wipe with no left-over data on the disk.
I'd recommend looking into libtrash. Very handy, saves stretch on your tapes -- we are keeping regular backups, right?
Another good tip that gets me sometimes is, when you use the paste buffer (explicit Ctrl-C), the originating program has to still be running to make the paste.
If you're not forced to do so, change it to sftp://. It is a much better solution if your ssh target has an sftp backend. FISH uses basic shell tools at the remote, like shfs, and that's just too much complexity to be a good solution.