Domain: logix.cz
Stories and comments across the archive that link to logix.cz.
Comments · 11
-
Re:Apple and the others...
This is exactly what the problem with iZealots. You don't even realize that your arguments are circular. It always comes down to basically claiming that Apple's products are the best because Apple's products are the best. I used my Sharp Zaurus for many years before Apple "invented" the handheld touch screen device. The only difference is that when Sharp came out with their Zaurus, there wasn't a huge iZealot fanbase to immediately proclaim it was the greatest thing since nothing else. You see the same thing in this article, dismissing the amazing advances that IBM (for example) has done, simply because they are not mass-consumer oriented. Without IBM, none of the stuff we take for granted today would even have been possible to build. That CPU inside your iWhatever? A RISC chip, no doubt. Invented by IBM. That hard drive with 300GB the size of a thumb nail? Uses GMR, no doubt. Invented by IBM.
So FUCK YOU Apple iZealots. Apple is not the be all and end all of innovation in this industry and it is extremely tiring to have to fight the revisionist history that you iZealots constantly promote.
-
Re:why is the Via C7 not more popular?
Erm, no, for developers there have been Linux kernel crypto modules supporting the Via Padlock included since 2.6.11, and if you don't want them, you can always use the crypto instructions directly. The Java is just an API option provided by Via.
-
Re:A Few Basic Questions
I use S3 by itself for off-site on-line backup.
Only pennies per month.
Automated access via s3cmd; http://s3tools.logix.cz/s3cmd
or http://s3sync.net/wiki -
Re:How fast is that?
Anybody, have an idea how fast that is compared to modern a CPU?
IIRC, the last time I did anything like this it took my 2200+ AMD about 24 hours to do a 6-character keyspace (from 64-character set) - with MD5.
You should compare against VIA hardware. Their CPUs are crap for general usage, but the crypto acceleration is really good:
http://www.logix.cz/michal/devel/padlock/bench.xp
Page doesn't seem to include MD5/SHA1 though, but you can compare that to AES on your box. -
Re:laptop anyone
OpenSSH can be hacked to use the hardware encryption engines using instructions on this site: http://www.logix.cz/michal/devel/padlock/index.xp
? show_selected=1&msgid=407.I've done this in the past when I used to run Gentoo on an Epia MII. Combined with the XvMC support it was a cracking MythTV/mini server.
-
Re:aes.ko Vs. aes-i586.ko: stats...
[...]not being fully i586 compatible. My little VIA M10000 MiniITX board springs immediately to mind as an example.
Well, I don't think so, VIA processors are rather compatible with i586. Slow as hell, but compatible. Quoting after cute page about some aspects of VIA processors, x86 processors are identified by family/model/stepping (F/M/S) triplet. My VIA Nehemiah processor identifies itself as 6/9/8, and family=6 means "i686 compatible" (i.e. compatible with original Pentium Pro instruction set).
Besides, if you have VIA 6/9/8 processor or higher (e.g. 6/10/0), you don't have to use aes-i586. Use "padlock" driver, which uses hardware AES engine on these processors, at least an order of magnitude faster than aes-i586, just as I wrote several levels higher, starting this thread ;)
Look up your F/M/S in /proc/cpuinfo.
Robert -
Re:The girl in the video is cute
-
Been done already
How about a picture of the FreeBSD demon sodomizing the Linux penguin?
Linky...can't ya just hear dueling banjos in the background? -
Re:I have an idea for a new FreeBSD logo
I was thinking of this.
;) -
Touchsrceens and boards
Lilliput 7" touchscreens are only $279 at www.mp3car.com. Prefect for and undercabinet mounting. Combine that with a mini-itx board and you have a great kiosk or mp3 car player.
Other links of interest:
Linux Touch Screen HOWTO
EPIA HOWTO
Gentoo EPIA HOWTO
Nehemiah Hardware Entropy Generator
VIA PadLock support for Linux
-
Re:OpenVPN
i also recommend openvpn. supported on a majority of systems: windows 2k/xp, linux, mac os x, bsds, & solaris. here's the howto.
imho, great example of kernel/user-land separation: tun/tap virtual device driver is the only kernel-side part, the rest is in user-land. no more having freeswan keep the system from cleanly shutting down because of a lost reference to a network device. but there is overhead from context switches between kernel & user, though it's a trade-off i think is worthwhile.
you can do ip or ethernet tunneling, depending how far down the osi model you want to go and how much overhead you are willing/able to process. with a single wireless client in my household, i do ethernet tunneling, as it frees me from having to do any ip routing and configuring a wins server (which i've found problematic with windows 2000 and samba 2.2 on debian stable).
openvpn openvpn can use shared key or tls, just depends on what you want. you can quickly develop a proof of concept with shared keys (prove software installation, network communication, etc work) and then "upgrade" to tls.
openvpn uses openssl for it's encryption/authentication engine. that means that all the scrutiny and improvements openssl receives (security analysis, assembly encoded algorithms, hardware engines, etc) benefits openvpn. i'm interested in doing openvpn on the via epia platform with hardware-assisted openssl serving as wireless xterminals.
encrypting lots of bandwidth means lots of processor cycles, and depending on the speed of your processors and the bandwidth between the two, expect some slow down. this is not particular to openvpn, but any (software) encryption, so choose your hardware accordingly (with lots of benchmarking for your particular use case).
ipsec is a valid option, though i prefer openvpn. ipsec is a standard, and is supported on more platforms than openvpn (especially embedded systems & dedicated hardware), but is firstly cumbersome to configure and secondly compatibility is theoretically possible between all implementation but not guaranteed. i once connected windows 2000 and linux/freeswan using ipsec. nate carlson's howto is invaluable. with linux 2.6 it's even harder to implement ipsec with iptables because neither the in-kernel ipsec implementation nor openswan support virtual interfaces (ipsec[0-9]). supposedly it's "possible" using iptables to tag packets, but i won't consider it "practical" until it's easy enough to be documented in a howto.