lilo relies on the FIBMAP ioctl in order to get the sectors occupied on the disk by a file.
It's the file system code in the kernel that should implement that ioctl.
Other than lilo and a stupid tool I've put together to force-blank the contents of a file, I don't know about any other user of that ioctl.
You are more than welcome to write your own grub.cfg file and make
it as bare as possible.
And it will be replaced the next time you update the kernel with apt-get upgrade.
And no, the grub.d idiocy is not a distribution thing: it's the recommended way to do things from upstream. Read the grub manual. grub.cfg was deliberately made more complex and obtuse in order to discourage people from messing with it by hand.
What pissed me more that that was that update-grub was running grub-probe some 20 times, each instance taking ~30 seconds and thrashing the disks violently.
Fortunately, on Debian it's pretty easy to stick with boot-legacy, which I did finally.
For anyone who had to suffer through Perl's unicode support, having
a separate set of functions for multibyte IS the right, sane approach.
In Perl, some strings are surreptitiously tagged as utf-8 and some not,
based on runtime switches, locale environment settings, and the phase
of the moon. You could never be sure if length($s) will return you
the length in 'characters' or the length in bytes. Even if you turn
utf-8 on overall, you still have to flag file names as utf-8 by hand,
one by one, to prevent perl from making a mess out of them.
'Transparent' support of unicode is a stupid, broken idea, and nobody
with a bit of clue will still be advocating it.
in Python (I'm no php expert) in order to
call a C function you must context switch (flush registers),
unbox the value into the native type, perform the operation,
rebox the value into the Python type, then context switch back
to the interpreter.
At no point there happens any context switch. I think you're terribly
confused about terms like 'native code' and 'interpreter' mean.
As to the boxing/unboxing of the arguments, it's pretty cheap; that's
certainly not the reason why these dynamic languages are so slow.
The real way to fix this is to reduce the demand. That can be arranged by cracking down on businesses who operate on US soil and hire illegal immigrants, by getting rid of bi-lingual everything and declaring the national language to be English, and by requiring proof of citizenship before... once you get here there's nothing for you
And at the end of that process USA will become a 'regular' country like Belarus or
North Korea, where people will be desperate to sneak out instead of in.
(e.g. freely using typecasts on pointers and expecting it to work because it points to the same memory address, while the optimizer legally assumes it doesn't).
care to elaborate?
I think you got that backwards.
In C, the optimizer must assume that any two random pointers (no matter what
their types are) may point to the same memory address -- and restrain itself
from being too smart. (Their are some exceptions, like the results from
malloc()).
Want to run new/updated software then you need to
drop some libraries in/usr/lib some resources in/usr/share etc.
No. You can install everything you want
(libraries, resources) under your home directory.
That's what LD_LIBRARY_PATH, the --prefix
option to configure, and many other facilities
are for.
Even if you're root, you can choose something
like/opt or/odd to install anything that
doesn't come with the distribution.
Manually poking inside the/usr/lib and dropping
random libraries there is about the most stupid
and ignorant thing one can do on a linux machine.
Are they still using a threaded perl on RH/Fedora/Centos ?
I used to know some funny stuff about how threading works in perl.
Briefly, it's a joke. If you want your perl to be at least 2 times
slower and 4 times as bloated for a typical workload, you compile it
with ithreads support. And nobody wants threads support - you should
be plain/crazy/ to use a perl threaded application in production.
Similarly, KDE/Qt and Gnome are accessed directly by many programs. Programs should be accessing X through the window manager.
That's not how it works.
A window manager is a regular X11 aplication (just like xclock or xterm). The only
special magic it setting the 'substructure redirect' flag on the root window of
the screen - which basically means that when another application asks the X server to
put a window on the screen, or modify its size or position, etc., the X server will
send a message with those parameters (window, size, position) to the window manager
instead of mapping/resizing the window outright.
Applications don't have to know a window manager even exist - they're supposed to
run fine even on the bare server. (but buggy applications/libraries DO assume a window
manager - for instance, firefox assumes it can keep the focus to the main window
after creating other top windows with the override-redirect flag set, which is
NOT the default in X11, unless KDE/Gnome/etc is there to make it look like it's Microsoft Windows;-))
Re:Anything else out there?
on
The State of X.Org
·
· Score: 4, Informative
Then, once you have decided to work on it and have fully absorbed X11 protocol into your being, you basically need a vmware license in order to develop. It's almost as hard to try out the changes you made as it is for kernel developers
You don't need any vmware license.
You can safely run more instances of the Xorg server on linux - just start on another
screen (ex. Xorg:1). It's just that easy - the server will run in another
virtual console. If you know you made changes that could lock up your screen/keyboard,
you could conveniently schedule an at(1) process to kill it after 2 minutes (or
ssh into the box from another machine).
And if your messing with video card driver code, then again vmware won't be of any use.
Unless you're working on the special driver for the vmware virtual video card itself.
And finally, at least for debugging and testing purposes, qemu (which is free)
works just as well as vmware.
I bet they could do it for half the price of the migration (5 million USD)
It's 8 million EURO, that's ~12 million USD, not 5.
And if you give me just 1 million, not 5 or 12, I'll wrap you about any windows
application to work on linux, in half the time they need to migrate their whole shit
to vista. Money-back guarantee.
Was valgrind complaining AT ALL about the second MD_Update()
(the one from ssleay_rand_add()) ?
The probability of a programmer modifying two separate
pieces of code --not exactly related-- on questionable look-alive
(the usage of MD_Update() is quite different in the two)
is really slim.
I'd rather buy into the conspiracy theory, where he deliberately
slipped this;-)
Slashdot Mirror
How could be a kernel panic the fault of KDE?
It's the file system code in the kernel that should implement that ioctl. Other than lilo and a stupid tool I've put together to force-blank the contents of a file, I don't know about any other user of that ioctl.
And it will be replaced the next time you update the kernel with apt-get upgrade.
And no, the grub.d idiocy is not a distribution thing: it's the recommended way to do things from upstream. Read the grub manual. grub.cfg was deliberately made more complex and obtuse in order to discourage people from messing with it by hand.
What pissed me more that that was that update-grub was running grub-probe some 20 times, each instance taking ~30 seconds and thrashing the disks violently.
Fortunately, on Debian it's pretty easy to stick with boot-legacy, which I did finally.
(And assume you want to install that crap in /usr).
In Perl, some strings are surreptitiously tagged as utf-8 and some not, based on runtime switches, locale environment settings, and the phase of the moon. You could never be sure if length($s) will return you the length in 'characters' or the length in bytes. Even if you turn utf-8 on overall, you still have to flag file names as utf-8 by hand, one by one, to prevent perl from making a mess out of them.
'Transparent' support of unicode is a stupid, broken idea, and nobody with a bit of clue will still be advocating it.
At no point there happens any context switch. I think you're terribly confused about terms like 'native code' and 'interpreter' mean.
As to the boxing/unboxing of the arguments, it's pretty cheap; that's certainly not the reason why these dynamic languages are so slow.
^W is the default for 'WERASE' (word-erase) on any unix terminal set in canonical mode.
RTFM: stty(1), termios(3).
It's supposed to erase words even when no line editing facility whatsoever is used.
The whole ^H, ^W meme has more to do with how actual terminals used to work than with those quaint ascii control codes.
RTFM, it can be fixed.
What "it" is true?
And at the end of that process USA will become a 'regular' country like Belarus or North Korea, where people will be desperate to sneak out instead of in.
The trauma control functions of my brain were trying to blot out any remembrance of the strict aliasing rules ;-)
And pay a hefty fine every time.
You'll find audio pronunciations if you choose eg. English-French or English-Chinese instead of English Dictionary on the drop-down menu.
No. You can install everything you want (libraries, resources) under your home directory. That's what LD_LIBRARY_PATH, the --prefix option to configure, and many other facilities are for.
Even if you're root, you can choose something like /opt or /odd to install anything that
doesn't come with the distribution.
Manually poking inside the /usr/lib and dropping
random libraries there is about the most stupid
and ignorant thing one can do on a linux machine.
locate(1) is absolutely worthless IMHO. It's one of that old stupid hacks that should have replaced LONG ago with something better.
I used to know some funny stuff about how threading works in perl.
Briefly, it's a joke. If you want your perl to be at least 2 times slower and 4 times as bloated for a typical workload, you compile it with ithreads support. And nobody wants threads support - you should be plain /crazy/ to use a perl threaded application in production.
Or just blacklist google-analytics entirely.
IIRC, it's Content -> Site Preferences or something like that. (I'm not using Opera anymore).
you're mom ?
I've never seen a cat eating insects.
A window manager is a regular X11 aplication (just like xclock or xterm). The only special magic it setting the 'substructure redirect' flag on the root window of the screen - which basically means that when another application asks the X server to put a window on the screen, or modify its size or position, etc., the X server will send a message with those parameters (window, size, position) to the window manager instead of mapping/resizing the window outright.
Applications don't have to know a window manager even exist - they're supposed to run fine even on the bare server. (but buggy applications/libraries DO assume a window manager - for instance, firefox assumes it can keep the focus to the main window after creating other top windows with the override-redirect flag set, which is NOT the default in X11, unless KDE/Gnome/etc is there to make it look like it's Microsoft Windows ;-))
You can safely run more instances of the Xorg server on linux - just start on another screen (ex. Xorg :1). It's just that easy - the server will run in another
virtual console. If you know you made changes that could lock up your screen/keyboard,
you could conveniently schedule an at(1) process to kill it after 2 minutes (or
ssh into the box from another machine).
And if your messing with video card driver code, then again vmware won't be of any use. Unless you're working on the special driver for the vmware virtual video card itself.
And finally, at least for debugging and testing purposes, qemu (which is free) works just as well as vmware.
And if you give me just 1 million, not 5 or 12, I'll wrap you about any windows application to work on linux, in half the time they need to migrate their whole shit to vista. Money-back guarantee.
Was valgrind complaining AT ALL about the second MD_Update() (the one from ssleay_rand_add()) ? The probability of a programmer modifying two separate pieces of code --not exactly related-- on questionable look-alive (the usage of MD_Update() is quite different in the two) is really slim.
I'd rather buy into the conspiracy theory, where he deliberately slipped this ;-)
Devs had to sign NDAs to get the specs for that Marvell wireless chip.