Re: 7-Zip / Bzip2
thegraze [EMAIL PROTECTED] wrote: But 7z is GPL! Which is not an impediment per-se. After all it's just a userland tool, not a library or even part of the kernel. Remember that gzip was GPL for a long time, before the NetBSD people started writing a replacement tool. On the other hand, it should be noted that both bzip2 and gzip (at least the one used by the BSDs) are now under BSD licenses. Replacing a BSD-licensed piece of software with a GPL-licensed one is only desirable if the latter is much more useful or has features that are needed, and if there are good reasons to have it in base instead of pkgsrc. So, is 7z useful enough to add a fourth compression tool to the base system? And keep it there forever? (Remember that we also have to keep compress(1) for compatibility, even though it compresses worse and is slower than gzip, so the usefulness is very small.) I've given it a quick test and fed a 1 MB logfile to 7z. It was only marginally better than bz2 ( 1%), but it was noticeably slower. And bz2 is already painfully slow for both compression and decompression. Not everybody has a 3 GHz multicore machine. That's why I still use gzip most of the time -- the compression is a little worse, but it's a *lot* faster. There were even cases when people reported that they weren't able to decompress a bz2 file on a small system (embedded or otherwise), because it required several MB of RAM for decompression. It appears that 7z is even worse. The memory footprint of gunzip is negligible. It should also be mentioned that about every other year another compression tool pops up that claims to be better than all the others. Last year (or the year before) it was paq, before that it was rzip and lrzip, and so on. So this year it is 7z. What will be the next one? So, my personal opinion is: Leave 7z in pkgsrc. Just my 2 cents ... Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
iwi problem with WEP
normally I use iwi(4) in combination with WPA and it works
mostly fine.
Now I'm forced to use WEP and can't get it working. ifconfig
looks ok, but dhclient does not. Setting the IP address
manually doesn't help either.
I think it has to do with WEP encryption. Does anyone use
iwi with WEP?
Johannes
ifconfig iwi0
iwi0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1492
inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255
ether 00:16:6f:64:b3:47
media: IEEE 802.11 Wireless Ethernet autoselect (DS/1Mbps)
status: associated
ssid Test channel 7 bssid 00:12:bf:41:c4:cf
authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpowmax 100
bmiss 7 protmode CTS roaming MANUAL bintval 100
wpa_supplicant.conf:
network={
ssid=Test
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0=00
Re: 7-Zip / Bzip2
Which is not an impediment per-se. After all it's just a userland tool, not a library or even part of the kernel. Not to nit-pick, but it's LGPL, not GPL, so it's not *so* bad :) So, is 7z useful enough to add a fourth compression tool to the base system? And keep it there forever? (Remember that we also have to keep compress(1) for compatibility, even though it compresses worse and is slower than gzip, so the usefulness is very small.) I would argue that 'compress' should be removed and put in the ports tree. There's always this argument concerning shell scripts that are still using these tools...who's using one? If you're swapping to DragonflyBSD, chances are you're not worried about breaking compatibility a little, and it's not difficult to put it in the docs that it's been removed. I've given it a quick test and fed a 1 MB logfile to 7z. It was only marginally better than bz2 ( 1%), but it was noticeably slower. And bz2 is already painfully slow for both compression and decompression. Not everybody has a bz2 is painfully slow for compression, not decompression. Small files aren't much of a concern for any of this, though. As I mentioned previously, if you use the compression level argument with 7z, you can beat bzip2 by compression AND speed in many cases. I compressed a 4gb image 90mb smaller and 3 minutes faster than bzip2 with 7z's compression level '4'. 3 GHz multicore machine. That's why I still use gzip most of the time -- the compression is a little worse, but it's a *lot* faster. I wasn't suggesting removal of gzip. Just like not everyone has a 3 GHz multicore machine, not everyone is still using a crappy 486 --- they shouldn't be limited by the restrictions your particular machine has. There were even cases when people reported that they weren't able to decompress a bz2 file on a small system (embedded or otherwise), because it required several MB of RAM for decompression. It appears that 7z is even worse. The memory footprint of gunzip is negligible. RAM usage for compression depends on the level of compression you're using. If someone's going to be using DflyBSD for an embedded device with limited resources, they would tailor it accordingly and remove 7zip and bzip2. A great many systems don't need half the kernel modules either, that doesn't mean those should not have been added to DFly. It should also be mentioned that about every other year another compression tool pops up that claims to be better than all the others. Last year (or the year before) it was paq, before that it was rzip and lrzip, and so on. So this year it is 7z. What will be the next one? 7-zip has been around since ~2000. It's not hype. rzip's features, having more flexibility than just 100-900k block sizes in bzip2, should've been available in bzip2 from the start -- unfortunately some of Unix's best strengths are its greatest weaknesses. bzip2 can't simply be altered, otherwise compatibility will be broken. bzip2 would never have been added if gzip could've been modified at whim. bzip2 vs 7z: - 7z supports listing decompressed size of contained file(s) - 7z can compress faster with a better ratio, or a much better ratio but slower - 7z can create volumes. while I realize one can use 'split'...try putting a huge set of volumes back together on windows. 7z has a really decent windows port, tooand ports on many other OSes. Best Regards, Ben Cadieux
Virtual kernels will be enabled for user execution on leaf this weekend
I will be upgrading LEAF to the latest HEAD and I will be enabling virtual kernel support runnable from user accounts this weekend. This is to help the Summer of Code projects. I am also going to create an easy-to-use build environment for building a vkernel and running a vkernel environment. I am also going to try to get it setup so user-run vkernels can access a local 10. network for easier access into the running vkernel. Note that leaf is not the fastest machine in the world, and using vkernels on it will be limited to 64-128MB memory images each. The purpose of the support will be to make it easier to develop kernel related projects. Any actual performance testing of your project would have to occur on real hardware. The vkernel memory and disk images people use will have to go into the un-backed-up build partition. I'll have more to announce on Sunday. -Matt
problem with xorg
Hi all, I'm configuring my X desktop, but X server outputs: Fatal server error: No valid FontPath can be found. What is the problem? Thanks, savio -- only the paranoid will survive
Re: problem with xorg
Hello, On Fri, 2008-05-09 at 23:50 +0200, dark0s Optik wrote: Hi all, I'm configuring my X desktop, but X server outputs: Fatal server error: No valid FontPath can be found. What is the problem? Thanks, savio It seems you forgot to install the modular-xorg-fonts package. Cristi -- Cristi Magherusan, Universitatea Tehnica din Cluj - Napoca Centrul de Comunicatii Pusztai Kalman Tel. 0264/401247 http://cc.utcluj.ro signature.asc Description: This is a digitally signed message part
Re: problem with xorg
I didn't find a modular-xorg-package in http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/DragonFly-1.12/stable/All/ 2008/5/10 Cristi Magherusan [EMAIL PROTECTED]: Hello, On Fri, 2008-05-09 at 23:50 +0200, dark0s Optik wrote: Hi all, I'm configuring my X desktop, but X server outputs: Fatal server error: No valid FontPath can be found. What is the problem? Thanks, savio It seems you forgot to install the modular-xorg-fonts package. Cristi -- Cristi Magherusan, Universitatea Tehnica din Cluj - Napoca Centrul de Comunicatii Pusztai Kalman Tel. 0264/401247 http://cc.utcluj.ro -- only the paranoid will survive
Re: problem with xorg
:Hi all, I'm configuring my X desktop, but X server outputs: : :Fatal server error: :No valid FontPath can be found. : :What is the problem? : :Thanks, :savio Yah, as Cristi indicated, you probably didn't install all the needed components. pkgsrc is kinda opaque about what actually needs to be installed to get xorg running. Not only do you want modular-xorg-fonts, you probably also want modular-xorg-server (which you probably did get), modular-xorg-drivers, and modular-xorg-apps. -Matt Matthew Dillon [EMAIL PROTECTED]
Re: problem with xorg
What is modular-xorg-fonts package in http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/DragonFly-1.12/stable/All/ ? 2008/5/10 Matthew Dillon [EMAIL PROTECTED]: :Hi all, I'm configuring my X desktop, but X server outputs: : :Fatal server error: :No valid FontPath can be found. : :What is the problem? : :Thanks, :savio Yah, as Cristi indicated, you probably didn't install all the needed components. pkgsrc is kinda opaque about what actually needs to be installed to get xorg running. Not only do you want modular-xorg-fonts, you probably also want modular-xorg-server (which you probably did get), modular-xorg-drivers, and modular-xorg-apps. -Matt Matthew Dillon [EMAIL PROTECTED] -- only the paranoid will survive
Re: problem with xorg
dark0s Optik wrote: I didn't find a modular-xorg-package in http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/DragonFly-1.12/stable/All/ You'll find it here: http://www.theshell.com/pub/DragonFly/packages/DragonFly-1.12/stable/All/
