"Huh? Are you saying that apt can't upgrade just one package at a time? That's absolutely false."
No.
I mean that if you do an "apt-get dist-upgrade" or similar task, apt will download every necessary package and do a: rpm -Uvh [every package that will be updated here]
URPMI can break the "[every package that will be updated here]" list into small upgradable islands.
I think this approach cleaner. You can observe that during an Mandrake upgrade thru Drakx if you change to the log console.
You can argue that it is not a problem if apt works that way. However, I have experienced problems with bad packaged packages that made the "rpm -Uvh" abort in the middle leaving my system unstable. It's true that it is not a apt problem, but with this kind of feature urpmi would make less damage if this happened.
There is no apt vs rpm as there is no urpmi vs dkpg. it is like comparing a beer (liquid) with a beer can.
APT is a great management tool. But it is not a packaging format/tool.
APT already works with Debian, debian dkpg based distros and some RPM based distros as: - Conectiva (they ported to rpm and support apt use) - Mandrake (at least for the cooker) - Redhat and Suse (thru 3rd party prepared mirrors)
An advantage of URPMI over APT is that URPMI can do small updates instead of taking the whole package list and putting it in a big "rpm -Uvh" command line.
Using a plugin^Mmodule interface to load schedulers at runtime wouldn't generate a performance impact in the scheduler? (as opposed to have the scheduler compiled inside the kernel).
I AFAIK, the scheduler has to be as compact (optimized) as possicible to reside as long as possible in the cpu's cache. This way it can check the memory pages map as fast as possible to [de]allocate, switch process as fast as possible.
Using a module scheduler, wouldn't make it have to derreference each function address each time each function is called? And probably sometimes derreferencing derreferences few times to get the correct address?
Couldn't this hurt performance?
I agree that loading an efficient scheduler to handle a situation better than the defalt scheduller would compensate for that, but still...
Is there a way to generate a PS file from OO's XML? (without using OO)
I have being looking for this for a while.
Messing with OO XML format is not difficult and if you just play with OO saved file to see what changes in the XML, it is easy to create reports from a scripting language (aka perl).
The problem is that (AFAIK), there is no way to direct print (or generate a PDF) without entering OO itself.
It should not be difficult to write a command line utility to do so, if someone who knows the API points to what would have to be done.
So, IMO, this is the missing key to Office XML perl Heaven!!!
I would recommend spending the 5$ or so to get a copy
of the air filters report from http://www.consumerreports.org
(no I don't work for them, I'm just a fan:)
Linus has stated tons of times and this has being covered tons of times everywhere.
You can have NON-GPL drivers in the Linux Kernel as a module. You won't be able to compile a monolithic kernel with your driver.
This means that you might need to use a initrd image if you need it at boot time.
Things can get messy if you need your driver to access some "virtual" fs to read the initrd image in the first place.
My advise is to try to convince your bosses that GPLing the drivers would make things really easy for you as a developer and can be shared with other embedded developers.
Specially if this is related to common pieces of hardware, like memories (flash,...), buses and so on. It is even possible that similar problems have being covered before and it is available (guess what...) under GPL.
Good places to start: http://www.linuxdevices.com http://alllinuxdevi ces.com
> M$ sales are pretty seasonal, hence the sample taken at the start of January, >most likeley OEMs stocking up for systems with the Next Big Thing from Intel. >Linux sales are from many distros, so are probably more constant. Remember also >that those numbers are probably pretty rounded.
Ok, I agree.
however this one can't be justified: 'accounts for one half of 1 percent of the total operating system revenue each year, or roughly two days'
>Besides, $80 sales ain't bad for a "free" OS;-) not at all.
After looking for a nice email client in Linux a came with the conclusion that what I need did not exist.
So 3 years ago I decided to write my own. Then I wrote Chaos' Mail Client as a pet project (It actually started ad Chaos' Mail Counter).
http://www.swi.com.br/~chaos/cmc
What I needed: - fast interface -> written in Perl with gtk+ - do not destroy corrupt mailboxes -> it uses c-client - access existen mbox without creating annoyning indexfiles which every other program do. - support a common location for the mailboxes -> ~/mail - Show how many messages is read/unread in a mailbox without the need to open the mailbox - work together with procmail and fetchmail - support multiple mail address as the sender. - display html mail (hey remember that it was 3 years ago without kmail, evolution, mozilla,...;) - support multiple smtps servers to send the mail (most clients uses sendmail to do it). - MIME support to view attatchments. - easy to extent -> written in perl and most features as perl modules.
It is not perfect, however it suits my needs for the past years I have being in Linux. It is being rewritten to get truly modular and allow a curses, qt, web interface to be written.
And a feature that every one wishes I just started to write: SpamCop.net support, so the user can have something to do with all those spams;)
apt-get[able] for Conectiva Linux
on
KDE 3.0 is Out
·
· Score: 5, Informative
KDE 3 is already apt-get_able for Conectiva Linux for a few days
Just make sure you have the snapshot in your/etc/apt/sources.list the lines:
rpm ftp://ftp.nl.linux.org/pub conectiva/snapshot/conectiva main extra orphan gnome experimental games kde rpm-src ftp://ftp.nl.linux.org/pub conectiva/snapshot/conectiva main extra orphan gnome experimental games kde
Why not using Conectiva Linux's Modular Instaler (MI) ? http://distro.conectiva.com.br
Conectiva has one of the best GPL instalers. It is: - modular, so you can easily create new modules, - light (the ncurses version needs less than 8MB of RAM) - apt centric, it should be really easy to adapt it to use deb instead of
rpm. and apt can be the hook here.
Slashdot Mirror
"Huh? Are you saying that apt can't upgrade just one package at a time? That's absolutely false."
No.
I mean that if you do an "apt-get dist-upgrade" or similar task, apt will download
every necessary package and do a:
rpm -Uvh [every package that will be updated here]
URPMI can break the "[every package that will be updated here]" list into small upgradable
islands.
I think this approach cleaner. You can observe that during an Mandrake upgrade thru Drakx if you change to
the log console.
You can argue that it is not a problem if apt works that way. However, I have experienced problems with bad packaged
packages that made the "rpm -Uvh" abort in the middle leaving my system unstable.
It's true that it is not a apt problem, but with this kind of feature urpmi would make less damage if this happened.
There is no apt vs rpm as there is no urpmi vs dkpg. it is like comparing a beer (liquid) with a beer can.
APT is a great management tool. But it is not a packaging format/tool.
APT already works with Debian, debian dkpg based distros and some RPM based distros as:
- Conectiva (they ported to rpm and support apt use)
- Mandrake (at least for the cooker)
- Redhat and Suse (thru 3rd party prepared mirrors)
An advantage of URPMI over APT is that URPMI can do small updates instead of taking the
whole package list and putting it in a big "rpm -Uvh" command line.
Using a plugin^Mmodule interface to load schedulers at runtime wouldn't generate
a performance impact in the scheduler? (as opposed to have the scheduler compiled
inside the kernel).
I AFAIK, the scheduler has to be as compact (optimized) as possicible to reside as long as possible
in the cpu's cache. This way it can check the memory pages map as fast as possible to [de]allocate,
switch process as fast as possible.
Using a module scheduler, wouldn't make it have to derreference each function address each time
each function is called?
And probably sometimes derreferencing derreferences few times to get the correct address?
Couldn't this hurt performance?
I agree that loading an efficient scheduler to handle a situation better than the defalt scheduller would
compensate for that, but still...
But what kind of extra processing does the controller/disk do that aliviates so much the I/O?
Does firewire/USB2 HDs have the same problem as ATA interface/drive?
Can someone point me differences in use of HDD related to file/system I/O?
I know that SCSI drivers are faster than IDE.
But why does a IDE driver makes the CPU/system go down to its knee?
IDE being slower than SCSI shouldn't hung the processor while waiting for the data.
The process will be BLOCKED longer but why the CPU hanging?
Can someone point to me a good explanation to what's going on?
I have tested some SATA drives (Seagates and Maxtors) with Silicon Image and NVidia chipsets.
In all cases I saw no difference to ATA drives.
Also how is Firewire and USB2 compared to [S]ATA drives related to performance/IO?
I wonder how long before it is hacked to fly thru Linux and Mac os X?
Can someone explain (or link) how does external HDs connected thru
USB2 or Firewire performs against conventional xATA and SCSI?
Are they reliable? Do they work well with linux?
I have seen articles about hacking firewire to connect HDs on MacOS X, but no word about its performance.
Is there a way to generate a PS file from OO's XML?
(without using OO)
I have being looking for this for a while.
Messing with OO XML format is not difficult and if you just
play with OO saved file to see what changes in the XML, it is easy
to create reports from a scripting language (aka perl).
The problem is that (AFAIK), there is no way to direct print
(or generate a PDF) without entering OO itself.
It should not be difficult to write a command line utility to do so,
if someone who knows the API points to what would have to be done.
So, IMO, this is the missing key to Office XML perl Heaven!!!
You are misleading what was said.
It was:
I would recommend spending the 5$ or so to get a copy
of the air filters report from http://www.consumerreports.org
(no I don't work for them, I'm just a fan:)
__THANK YOU__
what I meant was that by the time I wrote that post, it wasn't too clear
that this was a problem related only no bind 4 and 8.
In no way I meant that this kind of news shouldn't be posted.
Just that a warning about which versions were flawed should be
specified.
Just old versions of bind,
Bind 4.x and 8.x are vulnerable to this.
Version 9, which is a complete rewrite from scratch
and the version that everyone running bind should be using,
does not suffer this security flaw.
Slashdot editors should take an extra care when posting
news like this to avoid FUD and unnecessary panic.
Linus has stated tons of times and this has being covered tons of times
...),
i ces.com
everywhere.
You can have NON-GPL drivers in the Linux Kernel as a module.
You won't be able to compile a monolithic kernel with your driver.
This means that you might need to use a initrd image if you need it at boot time.
Things can get messy if you need your driver to access some "virtual" fs to read
the initrd image in the first place.
My advise is to try to convince your bosses that GPLing the drivers would make things
really easy for you as a developer and can be shared with other embedded developers.
Specially if this is related to common pieces of hardware, like memories (flash,
buses and so on. It is even possible that similar problems have being covered before
and it is available (guess what...) under GPL.
Good places to start:
http://www.linuxdevices.com
http://alllinuxdev
Has anyone notived that has become too common on /. to get the same news over and over again?
What's wrong with saving it in the browser
rather than a third party "Evil" server?
One of the features I really miss in perl is a clean way to pre-compile
scripts. Both to speedup loading times and to byte-[en]code to program.
There is perlcc, which really isn't supported as a production tool and doesn't take
modules into account.
What do you think about technologies like Zend?
Is this really a issue for perl? or just a matter of time?
This interview should help to enhance the questions.
AWK couldn't handle opening and closing multiple files at that time.
This is answered in Chapter 27 page 645-647 of the camel book.
Please let's keep with questions not answered already.
MS runs Exchange. It handles 100000+ PC's all over the globe.
So, one globe, one server and it is windows.
right...
> M$ sales are pretty seasonal, hence the sample taken at the start of January,
;-)
:)
>most likeley OEMs stocking up for systems with the Next Big Thing from Intel.
>Linux sales are from many distros, so are probably more constant. Remember also
>that those numbers are probably pretty rounded.
Ok, I agree.
however this one can't be justified:
'accounts for one half of 1 percent of the total operating system revenue each year, or roughly two days'
>Besides, $80 sales ain't bad for a "free" OS
not at all.
The market share of "users" is a lot bigger.
Linux total sales == 1% Total OS sales
Linux sales == 2 days MS OS sales
2 days MS OS sales == 1% Total OS sales
365 days MS OS sales == 182,5% total sales
note that other OS vendors (specially unix ones) has
some participation. (less quantity, more expensive OSes).
This can only mean that there are some people paying
the costumers to get there OS to generate -82,5% of total
sales.
Maybe its about time to Sun to reconsider a more open License to it.
[L]GPLing it might give it the boost it needs.
After looking for a nice email client in Linux a came with the conclusion
... ;)
;)
that what I need did not exist.
So 3 years ago I decided to write my own.
Then I wrote Chaos' Mail Client as a pet project (It actually started ad
Chaos' Mail Counter).
http://www.swi.com.br/~chaos/cmc
What I needed:
- fast interface -> written in Perl with gtk+
- do not destroy corrupt mailboxes -> it uses c-client
- access existen mbox without creating annoyning indexfiles which every other program do.
- support a common location for the mailboxes -> ~/mail
- Show how many messages is read/unread in a mailbox without the need to open the mailbox
- work together with procmail and fetchmail
- support multiple mail address as the sender.
- display html mail (hey remember that it was 3 years ago without kmail, evolution, mozilla,
- support multiple smtps servers to send the mail (most clients uses sendmail to do it).
- MIME support to view attatchments.
- easy to extent -> written in perl and most features as perl modules.
It is not perfect, however it suits my needs for the past years I have being in Linux.
It is being rewritten to get truly modular and allow a curses, qt, web interface to be written.
And a feature that every one wishes I just started to write:
SpamCop.net support, so the user can
have something to do with all those spams
KDE 3 is already apt-get_able for Conectiva Linux for a few days
/etc/apt/sources.list the lines:
Just make sure you have the snapshot in your
rpm ftp://ftp.nl.linux.org/pub conectiva/snapshot/conectiva main extra orphan gnome experimental games kde
rpm-src ftp://ftp.nl.linux.org/pub conectiva/snapshot/conectiva main extra orphan gnome experimental games kde
then:
apt-get update
apt-get install task-kde
apt-get clean
and go for it.
of course if you are not using the snapshot version yet, you might want to:
apt-get dist-upgrade
Why not using Conectiva Linux's Modular Instaler (MI) ? http://distro.conectiva.com.br
Conectiva has one of the best GPL instalers.
It is:
- modular, so you can easily create new modules,
- light (the ncurses version needs less than 8MB of RAM)
- apt centric, it should be really easy to adapt it to use deb instead of
rpm. and apt can be the hook here.