I get a clock counting down and a broken image icon.
I enter "broken", then hit "label". Nothing happens. I enter "404", then hit "label". Nothing happens. I enter "error", then hit "label". Nothing happens. I enter "failure", then hit "label". Nothing happens. I hit "pass", which turns that button grey. Nothing much else happens. Eventually the clock stops at 0. Still nothing interesting happens.
This all looks like some kind of elaborate joke, getting people to screw with a web page that doesn't really do anything.
Uh, I don't know... PASS. Huh? Nothing happened. OK, label it "text". Huh? Nothing much is happening. Grrr...
WTF am I supposed to do? How do I go to the next image? What happens to my view if the other person does PASS, sits on his ass, labels something (match or not), or closes his web browser?
sRGB uses a gamma consisting of a linear portion near black and 1/2.4 elsewhere, for a total result that is ALMOST 1/2.2
"almost"
in other words, "different"
Of course, then there is the issue of reality. Gamma is usually wrong. Most anything between 1/2.0 and 1/2.5 is really a crude way to say "like some random monitor I used", which is essentially what sRGB is intended to represent. Probably half the files marked 1/1.0 are really sRGB as well. Other values (... 1/0.9, 1/1.1... 1/1.9, 1/2.6...) stand a decent chance of being correct. It'd be quite reasonable for a browser to assume that anything in the 1/2.0... 1/2.5 range can go direct to screen.
Current money flow: patient to doctor to insurance to lawyer+patient Proper money flow: patient to insurance to patient
That is, the patient should be buying insurance to cover any errors made by the doctor. Doctors should not be liable. This way, the doctor bills are much lower and the patients can choose what quality of insurance to buy. (with "none" being a legit choice) The doctor doen't need to mess with insurance, and lawyers are less needed.
That'll never happen because we elect lawyers. Doh!
If a doctor does something which is not a legit accident, I still don't want him liable. I generally want him in jail. Mere stupidity means losing the license to practice, along with some sort of review of the school he attended.
Liability turns hospitals into casinos. With the right injury, you get the jackpot. People who want to play that game should be buying their own insurance so that the doctors don't have to be involved.
Re:Yes, Debian supports multiple gcc versions.
on
The Future of NetBSD
·
· Score: 1
Since your URL is www.cross-lfs.org, your opinion certainly doesn't count! Compiling gcc is not my idea of fun. I guess it's not as dreadful as it was back in the 3.x days, but still... no thanks.
Debian makes it easy. If gcc 4.5 were available, "aptitude install gcc-4.5" would give me a "gcc-4.5" command. I set CC=gcc-4.5 to use it, rather than mucking with CFLAGS in some app's unfamiliar build system.
For easy cross-compiling I'd want this in/usr/bin:
Then in ~/somearch/ I put symlinks to those, using the plain (gcc, ld, etc.) names. This lets me select the crosscompilers with my PATH environment variable.
So I never need a -V or -b option, and I probably don't need to hack any Makefile or configure script. Changing CFLAGS tends to break things, such as when the original Makefile needed -fPIC or -fno-strict-aliasing to build things correctly. Nearly always, it is safe to override CC on the "make" command line.
Sane: do crypto in the app, so the database never sees unencrypted data Sane: do access control in the database Crazy: encrypt parts of the database, but the database has the crypto key...
Yeah, at 800x600 you do have to take drastic measures.
I wouldn't bother with X in that case. I used to use the SVGATextMode program to get a non-standard text mode. I'd get something weird like 117x42 on the Linux console.
If you can't get SVGATextMode to work, perhaps OpenBSD has something similar to the Linux framebuffer console.
I should know. I bought a genuine Digital VT100 for $30 back in 1993 or 1994.
It was an off-white color. You could call it beige I suppose. It wasn't as colorful as amber. I guess you could compare it with a light bulb in the 15-watt to 40-watt range.
Amber was very popular in that era as well. My other terminals, made by Televideo I think, were amber.
For sharpness: the green value matters most, the blue value does not matter at all, and the red value matters almost as much as green.
Emacs isn't fast-starting, which really hurts, but it does interact well with the debugger. I think there is a way to have emacs pop up new windows from an existing instance, similar to the way a web browser or office suite typically works. That might be reasonably fast.
I'm not sure it's just personal taste. The hardware matters.
I use black-on-white with virtually anything connected by the 15-pin VGA connector, and often when stuck with a scaled LCD. It is especially important to do this with a high dot clock (high resolution and high frame rate) because of the way display gamma interacts with bandwidth limits.
I use white-on-black with a very old CRT, such as the genuine Digital VT100. Those displays were designed prior to the whole WYSIWYG era, and thus don't cope with black-on-white very well.
I also use white-on-black with native-mode a **digitally** connected LCD, such as a laptop display or when using the DVI-D connector. This is the best.
First of all, FFS has all the complexity and overhead of a filesystem designed for rotating media. On a real disk, seeks are slow. On flash, seeks are nearly free.
You are probably using ATA flash. This isn't "real" flash. Block zero isn't the real block zero, block one isn't the real block one. When you write to the flash, the device uses a wear-leveling algorithm to avoid burning out one part of the flash early. Blocks are getting remapped in the hardware.
On "real" flash, you don't get that. The OS must do the wear leveling. You could write a block device driver that did this, but it's better to design a filesystem specifically for flash. Flash has odd properties. Typical: you can write a "1" bit anywhere, or clear a whole 256 kB to all "0" bits. Clearing a 256 kB chunk is what causes wear, so you must avoid that. You kind of want a log-based filesystem, but writing out a "1" bit should be done directly.
Linux supplies jffs, jffs2, and (soon) logfs for this task. The joke is that the jffs2 filesystem is log-based, while the logfs filesystem is journalling.
I do this all the time, using a simple editor which is similar (text-only, fast-starting) to vi.
I just open 20 or more xterm windows.
Probably that seems insane to you. It is, if you don't free yourself from the Windows-style desktop. I can deal with dozens of windows with little effort by setting up a traditional workstation-style environment:
a. focus-follows-mouse, not click-to-focus b. never minimize, maximize, or roll-up c. 6 to 12 virtual desktops (use them all) d. never use the GUI file manager or desktop icons e. traditional xterm, white on black, default font
You'll want a native-resolution LCD (digital connector, not VGA connector) of at least 1600x1024. Go with 2560x1600 if you can afford it.
BTW, if you really need to actively edit all those files, see if the task might be scriptable. The sed and awk commands are great. You can use perl too, right on the command line instead of with a script file.
The USSR trusted this guy enough to let him out (probably a family at home to torture if need be) and valued his work enough, so he gets sent to Silicon Valley.
My uncle needs something. OK, a quick trip to the supermarket. The russian guy goes missing. After a search, they find him in the corner of the store, crying.
I never ever heard a Linux kernel developer dare mention an IDE. Most use fast-starting simple little text-only editors.
Linux: microemacs (uemacs) and NO DEBUGGER Alan Cox: joe Andrew Morton: some toy like pico or maybe nano if I remember right
An IDE is perfect for slapping together a Visual Basic business app.
BTW, out of that 7 million lines: over 5% is assembly, and there is a goto at least every 200 lines. You're not making a UML diagram out of that! Despite that, which surely horrifies the IDE addicts, hard-core programmers find Linux to be very readable.
There are the old tools of course, cscope and cflow, but also new stuff.
Check out www.opensolaris.org's source browser. Go to http://lxr.linux.no/ to see Linux in a different source browser. I know the latter is available as source; I'm pretty sure the OpenSolaris one is too.
Use the editor for editing, and the browser for browsing. Makes sense, hmmm?
Some of these things are integrated with the version control, allowing quick access to prior revisions.
"The fact that I do not have these tools integrated in an environment similar to something like Visual C's means I have to do a lot of switching between terminal sessions."
Rethink your desktop, abandoning the Windows-like defaults you were given. Do like the UNIX workstation users. Example:
Put a thick (50 to 60 pixel) gnome task bar at the bottom. Eliminate the one at the top. Put a 5x2, 4x2, or 3x2 virtual desktop selector thing on the task bar. Set your window policy to the traditional UNIX-style focus-follows-mouse. Never ever minimize, maximize, or roll up a window; simply spread them across the virtual desktops. You should use the traditional xterm, white on black, with the default font. (80x70 characters is good) A sharp LCD (native resolution, digital connector) is strongly suggested, at a minimum resolution of 1600x1024. Choose a fast-starting editor: original vi, joe (like WordStar), microemacs, or even (ick) pico. Linus uses microemacs; the source is on the kernel.org site probably under the name uemacs. Never use the file manager or file selector if you can possibly avoid it.
That's what the real hackers use, at least when the hardware is available. It's an upgrade from the "screen" program or the Linux console virtual terminals, without much change to the tried-and-true work habits.
You don't have to go with that exactly, but it's clear that your current setup isn't working for you. An IDE is a workaround, not a proper fix. An IDE only helps with one very specific task. A proper fix will make you more efficient at many other tasks. You might even start to like the gimp (zillions of windows instead of tabs) or set your web browser to open windows instead of tabs.
BTW, learn the extra tools. Valgrind usually whips gdb. You may also like ltrace, strace, nm, eu-readelf or readelf, oprofile, etc. Rarely will you find an IDE button to make these tools run. Learn the shell, really: you can do loops right on the command line, backtick substitution, etc.
You're clueless, and you just let everybody know it.
64-bit code does indeed run faster. The data may be bigger, but the code (.text segment) is actually smaller. There are more registers. The calling convention for 64-bit Linux can pass up to 6 integers in registers. Stack accesses are greatly reduced. This is enough to be noticable to casual observation.
A typical modern Linux has only a handful of 32-bit binaries, certainly not including the web browser. OpenOffice.org is even 64-bit now. Some systems don't even include the 32-bit libraries anymore, thus being unable to run 32-bit apps.
Running 32-bit stuff is gross. It's like running 680x0 code on a Mac, or 16-bit DOS apps on Windows. Normal people hate that.
Slashdot Mirror
I get a clock counting down and a broken image icon.
I enter "broken", then hit "label". Nothing happens.
I enter "404", then hit "label". Nothing happens.
I enter "error", then hit "label". Nothing happens.
I enter "failure", then hit "label". Nothing happens.
I hit "pass", which turns that button grey.
Nothing much else happens.
Eventually the clock stops at 0.
Still nothing interesting happens.
This all looks like some kind of elaborate joke,
getting people to screw with a web page that doesn't
really do anything.
Uh, I don't know... PASS. Huh? Nothing happened. OK, label it "text". Huh? Nothing much is happening. Grrr...
WTF am I supposed to do? How do I go to the next image? What happens to my view if the other person does PASS, sits on his ass, labels something (match or not), or closes his web browser?
Does this even work with firefox at all?
Do we get porn?
Sure, many businesses are mismanaged.
Lots of us do care about power. We fill racks with at least two VIA chips per 1U slot. Errr... VIA isn't made by AMD. Well, good luck to them!
AMD now provides a TSC (cycle counter) that doesn't vary in speed when the core speed changes. This greatly helps with timekeeping.
As for race conditions: that is pretty well taken care of already. SGI has Linux on a 2048-way system now.
sRGB does not use a gamma of 1/2.2
... 1/1.9, 1/2.6 ...) stand a decent chance of being correct. It'd be quite reasonable for a browser to assume that anything in the 1/2.0 ... 1/2.5 range can go direct to screen.
sRGB uses a gamma consisting of a linear portion near black and 1/2.4 elsewhere, for a total result that is ALMOST 1/2.2
"almost"
in other words, "different"
Of course, then there is the issue of reality. Gamma is usually wrong. Most anything between 1/2.0 and 1/2.5 is really a crude way to say "like some random monitor I used", which is essentially what sRGB is intended to represent. Probably half the files marked 1/1.0 are really sRGB as well. Other values (... 1/0.9, 1/1.1
Consider what happens when a doctor screws up:
Current money flow: patient to doctor to insurance to lawyer+patient
Proper money flow: patient to insurance to patient
That is, the patient should be buying insurance to cover any errors made by the doctor. Doctors should not be liable. This way, the doctor bills are much lower and the patients can choose what quality of insurance to buy. (with "none" being a legit choice) The doctor doen't need to mess with insurance, and lawyers are less needed.
That'll never happen because we elect lawyers. Doh!
If a doctor does something which is not a legit accident, I still don't want him liable. I generally want him in jail. Mere stupidity means losing the license to practice, along with some sort of review of the school he attended.
Liability turns hospitals into casinos. With the right injury, you get the jackpot. People who want to play that game should be buying their own insurance so that the doctors don't have to be involved.
Since your URL is www.cross-lfs.org, your opinion certainly doesn't count! Compiling gcc is not my idea of fun. I guess it's not as dreadful as it was back in the 3.x days, but still... no thanks.
/usr/bin:
Debian makes it easy. If gcc 4.5 were available, "aptitude install gcc-4.5" would give me a "gcc-4.5" command. I set CC=gcc-4.5 to use it, rather than mucking with CFLAGS in some app's unfamiliar build system.
For easy cross-compiling I'd want this in
somearch-gcc, somearch-ld, somearch-gas, somearch-cpp, somearch-g++
Then in ~/somearch/ I put symlinks to those, using the plain (gcc, ld, etc.) names. This lets me select the crosscompilers with my PATH environment variable.
So I never need a -V or -b option, and I probably don't need to hack any Makefile or configure script. Changing CFLAGS tends to break things, such as when the original Makefile needed -fPIC or -fno-strict-aliasing to build things correctly. Nearly always, it is safe to override CC on the "make" command line.
Sane: do crypto in the app, so the database never sees unencrypted data
Sane: do access control in the database
Crazy: encrypt parts of the database, but the database has the crypto key...
Yeah, at 800x600 you do have to take drastic measures.
I wouldn't bother with X in that case. I used to use the SVGATextMode program to get a non-standard text mode. I'd get something weird like 117x42 on the Linux console.
If you can't get SVGATextMode to work, perhaps OpenBSD has something similar to the Linux framebuffer console.
Get a dictionary. Look up "minimum".
At "only" $2000 now, I think the 2560x1600 displays are well worth the price. Some people are poor though.
I should know. I bought a genuine Digital VT100 for $30 back in 1993 or 1994.
It was an off-white color. You could call it beige I suppose. It wasn't as colorful as amber. I guess you could compare it with a light bulb in the 15-watt to 40-watt range.
Amber was very popular in that era as well. My other terminals, made by Televideo I think, were amber.
For sharpness: the green value matters most, the blue value does not matter at all, and the red value matters almost as much as green.
gdb itself can spit out the line of code.
Emacs isn't fast-starting, which really hurts, but it does interact well with the debugger. I think there is a way to have emacs pop up new windows from an existing instance, similar to the way a web browser or office suite typically works. That might be reasonably fast.
For graphical debugging: ddd
I'm not sure it's just personal taste. The hardware matters.
I use black-on-white with virtually anything connected by the 15-pin VGA connector, and often when stuck with a scaled LCD. It is especially important to do this with a high dot clock (high resolution and high frame rate) because of the way display gamma interacts with bandwidth limits.
I use white-on-black with a very old CRT, such as the genuine Digital VT100. Those displays were designed prior to the whole WYSIWYG era, and thus don't cope with black-on-white very well.
I also use white-on-black with native-mode a **digitally** connected LCD, such as a laptop display or when using the DVI-D connector. This is the best.
No, NetBSD requires an MMU. Linux doesn't need one. If you want to go where Linux can't go, you need eCos.
First of all, FFS has all the complexity and overhead of a filesystem designed for rotating media. On a real disk, seeks are slow. On flash, seeks are nearly free.
You are probably using ATA flash. This isn't "real" flash. Block zero isn't the real block zero, block one isn't the real block one. When you write to the flash, the device uses a wear-leveling algorithm to avoid burning out one part of the flash early. Blocks are getting remapped in the hardware.
On "real" flash, you don't get that. The OS must do the wear leveling. You could write a block device driver that did this, but it's better to design a filesystem specifically for flash. Flash has odd properties. Typical: you can write a "1" bit anywhere, or clear a whole 256 kB to all "0" bits. Clearing a 256 kB chunk is what causes wear, so you must avoid that. You kind of want a log-based filesystem, but writing out a "1" bit should be done directly.
Linux supplies jffs, jffs2, and (soon) logfs for this task. The joke is that the jffs2 filesystem is log-based, while the logfs filesystem is journalling.
Debian and Gentoo are both more clear and concise than that. Neither has changed in many years AFAIK.
I'm pissed that nobody else seems to do this. Not even Gentoo can do it, at least not with mere mortal admin skills.
/etc/alternates directory.
:-)
On my Debian box, I just typed "gcc\t\t" at the bash prompt. (tab twice to display completions) I get this:
gcc gcc-3.2 gcc-4.0 gccbug-3.0 gccbug-3.4 gccmakedep
gcc-2.95 gcc-3.3 gcc-4.1 gccbug-3.2 gccbug-4.0
gcc-3.0 gcc-3.4 gccbug gccbug-3.3 gccbug-4.1
Right now, plain gcc maps to gcc-4.0. I'm 95% sure I can change that via symlinks in the
Dang, I have 7 installed. I should probably delete a few.
Linux does not even require an MMU. When you want portability, you use Linux.
I do this all the time, using a simple editor which is similar (text-only, fast-starting) to vi.
I just open 20 or more xterm windows.
Probably that seems insane to you. It is, if you don't free yourself from the Windows-style desktop. I can deal with dozens of windows with little effort by setting up a traditional workstation-style environment:
a. focus-follows-mouse, not click-to-focus
b. never minimize, maximize, or roll-up
c. 6 to 12 virtual desktops (use them all)
d. never use the GUI file manager or desktop icons
e. traditional xterm, white on black, default font
You'll want a native-resolution LCD (digital connector, not VGA connector) of at least 1600x1024. Go with 2560x1600 if you can afford it.
BTW, if you really need to actively edit all those files, see if the task might be scriptable. The sed and awk commands are great. You can use perl too, right on the command line instead of with a script file.
The USSR trusted this guy enough to let him out (probably a family at home to torture if need be) and valued his work enough, so he gets sent to Silicon Valley.
My uncle needs something. OK, a quick trip to the supermarket. The russian guy goes missing. After a search, they find him in the corner of the store, crying.
I never ever heard a Linux kernel developer dare mention an IDE. Most use fast-starting simple little text-only editors.
Linux: microemacs (uemacs) and NO DEBUGGER
Alan Cox: joe
Andrew Morton: some toy like pico or maybe nano if I remember right
An IDE is perfect for slapping together a Visual Basic business app.
BTW, out of that 7 million lines: over 5% is assembly, and there is a goto at least every 200 lines. You're not making a UML diagram out of that! Despite that, which surely horrifies the IDE addicts, hard-core programmers find Linux to be very readable.
There are the old tools of course, cscope and cflow, but also new stuff.
Check out www.opensolaris.org's source browser. Go to http://lxr.linux.no/ to see Linux in a different source browser. I know the latter is available as source; I'm pretty sure the OpenSolaris one is too.
Use the editor for editing, and the browser for browsing. Makes sense, hmmm?
Some of these things are integrated with the version control, allowing quick access to prior revisions.
Rethink your desktop, abandoning the Windows-like defaults you were given. Do like the UNIX workstation users. Example:
Put a thick (50 to 60 pixel) gnome task bar at the bottom. Eliminate the one at the top. Put a 5x2, 4x2, or 3x2 virtual desktop selector thing on the task bar. Set your window policy to the traditional UNIX-style focus-follows-mouse. Never ever minimize, maximize, or roll up a window; simply spread them across the virtual desktops. You should use the traditional xterm, white on black, with the default font. (80x70 characters is good) A sharp LCD (native resolution, digital connector) is strongly suggested, at a minimum resolution of 1600x1024. Choose a fast-starting editor: original vi, joe (like WordStar), microemacs, or even (ick) pico. Linus uses microemacs; the source is on the kernel.org site probably under the name uemacs. Never use the file manager or file selector if you can possibly avoid it.
That's what the real hackers use, at least when the hardware is available. It's an upgrade from the "screen" program or the Linux console virtual terminals, without much change to the tried-and-true work habits.
You don't have to go with that exactly, but it's clear that your current setup isn't working for you. An IDE is a workaround, not a proper fix. An IDE only helps with one very specific task. A proper fix will make you more efficient at many other tasks. You might even start to like the gimp (zillions of windows instead of tabs) or set your web browser to open windows instead of tabs.
BTW, learn the extra tools. Valgrind usually whips gdb. You may also like ltrace, strace, nm, eu-readelf or readelf, oprofile, etc. Rarely will you find an IDE button to make these tools run. Learn the shell, really: you can do loops right on the command line, backtick substitution, etc.
If you're so die-hard that the built-in vi isn't real enough for you, why not?
Emacs can open a window for shell commands or to do a compile. Running vi is certainly something you could do. You could even bind it to a key.
You're clueless, and you just let everybody know it.
64-bit code does indeed run faster. The data may be bigger, but the code (.text segment) is actually smaller. There are more registers. The calling convention for 64-bit Linux can pass up to 6 integers in registers. Stack accesses are greatly reduced. This is enough to be noticable to casual observation.
A typical modern Linux has only a handful of 32-bit binaries, certainly not including the web browser. OpenOffice.org is even 64-bit now. Some systems don't even include the 32-bit libraries anymore, thus being unable to run 32-bit apps.
Running 32-bit stuff is gross. It's like running 680x0 code on a Mac, or 16-bit DOS apps on Windows. Normal people hate that.