Project Logs

Collapse

• UEFI RANT

  Eric Hertz • 05/26/2019 at 04:42 • 17 comments

  I give up, seriously!

  This be another rant...

  Seriously, when I was 15, I was so good at Intel/Windows/Linux systems that i was granted the highest-level admin privileges for a business with so many users MS-Outlook's contact-list system couldn't even handle them all. It, literally, stated that there were too many users to load... As I recall, that was something like 30,000.

  At the time, I was mostly handling lower-level stuff; loading OS's on new machines, etc.

  (SUBRANT: I FINALLY located a blutooth keyboard with an ESC key, so I can use VIM on my goddamned phone, because computers are SHIT these days, and phones are SHITTER... but that's another rant, which is coming soon to a scroll-down near you. Anyhow, this damned keyboard has [forward] DELETE as the BIG button next to "+", as opposed to BACKSPACE, which is a button in the upper-right-corner next to F12... WHAT THE HELL?! I mean, seriously, I must've found myself in hell, no? ESCAPE on my other keyboard is "HOME"... BACKSPACE on this keyboard is FORWARD-DELETE. WHAT THE HELL?!)

  Alright, where was I...? OH...

  So, for 30 years, computers could boot the exact same way... No joke. You could literally throw a DOS 3.2 boot-floppy from the PC/XT era in my Pentium 4's floppy drive, and... it'd boot... Throw a DOS 6.22 boot/install disk in that same machine, and you could literally install an operating-system from twenty years prior on a hard-disk made twenty years later.

  Sure, there may've been a few technicalities, a few limitations... Maybe greater-than 2GB was too much to ask, but I never ran into a case where FDISK wouldn't even detect the dang drive, at all! 

  And, again. I worked in friggin' IT, in the level of installing friggin' operating-systems on machines of countless-vintages.

  ------

  Now, somewhere in my college-years, when I thought I'd be getting into research instead of IT, I kinda lost-touch with the ol' computer-state-of-the-art... But, again, the state-of-the-art for the THIRTY years prior was that every new generation of [x86] computers was so much backwards-compatible with the previous generations that all you had to do was plop an older boot-disk into a newer machine and power it up...

  Now, I dunno what happened in the less-than-1/4 of that intercompatibility-period that followed my leaving the field, but now I've got TWO damned x86-64 [compatible] machines which won't load WinXP. We're talking less than a decade, here... Nevermind the THREE decades DOS6.22 would load without a hitch. The THREE decades FDISK.EXE would detect your drive, whether it was MFM, IDE, UDMA, or even SATA... Heck, given a decent BIOS or BIOS-extension, DOS would even detect SCSI drives, even in the PC/XT era.

  Yet, now, even with a BIOS/UEFI-configuration-setting for SATA's Legacy-mode, nary an OS-Installer-boot-disk I've access to (From WinXP to Win7) will detect the friggin' most important piece of hardware in the machine... the friggin' hard drive. 

  I'm sick of it.

  Frankly...

  That's all it boils down to. COMPUTERS ARE STUPID. And the designers, apparently, are getting exponentially stupider every year.

• To the dude who thinks learning to program a parallel port is so passe

  Eric Hertz • 05/18/2019 at 05:58 • 1 comment

  Was to be submitted to a post on some forum... Dude was *blessed* to (still) be taking a class where low-level programming of parallel ports was taught... And was downright obnoxious about it... "Because I live in 2011."

  Yeahp... this is nothing but a rant...

  LOL, attitudes like these are why we have super-computers thousands of times more powerful than took us to the moon--hundreds of times more powerful than those that rendered Toy Story--in our pockets to be dropped in toilets when we're dissatisfied with what we've got, rather'n someone's finally, for godsakes, recognizing that we already have far more than enough, if we'd quit pretending we know more than the previous generation, and winding up subjecting everyone, including the previous experts, do the newly-designed square wheel, to slowly chisel those corners once again. Seriously, when computers were *dozens* of times less powerful, we had multi-level undo, undo-histories where a single step in the history could be removed or modified, and all those following still applied... when computers were *hundreds* of times less powerful, we had undo and redo (to, yahknow, undo an undo). And here in an era of super-super-computers we'd be friggin' lucky if by installing an app from a questionable source that requires opening up security holes on one of our single most important devices in our lives, we *might* get access to a CTRL key on our screen, that *might* give us the ability to *try* CTRL-Z... which we have to do since, attitudes like these decided generations' worth of experience somehow was completely worthless in this new era... wherein menus were deemed old-tech in favor of context-sensitive-menus (which were a great invention, akin to the screwdriver after the hammer, not a replacement a DIFFERENT tool), which were then deemed old-tech in favor of (what?!). Meanwhile, hundreds of CPU-Powers less than we have now also had *multitasking*... and now that we have hyperthreading and multiple-cores, we can't even have two damned windows running side-by-side, because that's too "old-school"... AT EASE mofos! (look it up).
  Seriously; yeah, maybe networking isn't the best class to be teaching fundamentals like these (inport, outport)... But, you should, instead of being so friggin' cocky, take a moment to step back and say "hmm, maybe this is an opportunity to learn something". Because, frankly, no matter how much you virtualize our systems, no matter how many layers of [hardware/software] abstraction you throw at our systems, Someone, Somewhere, actually has to understand how to interface the friggin' Power/Charge LED with your multi-core ARM 2GHz processor. This is your chance to learn it, something very few are exposed to these days, and you think you're somehow above that. And, worse, completely disregard the fact that it still exists and will continue to as long as hardware and firmware exists. 
  And then, to top it off, you're too damned busy to be bothered to visit the lab where the systems are at your disposal *waiting* to be used... A lab where you could in fact be learning these *rare* opportunities *alongside* others, and instead, choose to figure out *extremely* difficult methods to emulate something you don't understand in the first place.
  And if that ain't enough. It's folks like you, with attitudes like yours, that have made it damned-near impossible for folks with *decades* of experience, *decades* of TOOL-development/improvements to make use of the TOOLs they've developed over decades... Why? Because y'all don't give a flying rat's ass about backwards-compatibility, even when someone like me comes around and shoves it in your face that it's not *backwards* compatibility *at all*, but LOW LEVEL compatibility, which, again, will exist as long an an LED or pushbutton needs to be interfaced with any sort of software.
  'cause some asshole like you will be a manager somewhere some day saying "why are we bothering with keyboard scancodes, when all our keyboards...

  Read more »

• The ridonculous era of overscan and hdmi

  Eric Hertz • 05/14/2019 at 03:51 • 1 comment

  This is a rant, that's all it is...

  Seriously...

  So here's the deal... TV's have historically displayed the image in such a way that the edges would be covered by the TV's housing. This, historically, was because, historically, TV-signals weren't perfectly-synchronized at the very beginning of each scan-line... so the [left] edge was pretty ugly. (and maybe the right, as well). Also, historically, people kinda preferred the "rounded" look of their old TV-sets, which meant that quite a bit of the once-square (by-design, not in reality) transmitted-image was hidden at the corners by, again, the TV's housing.

  Frankly, it didn't really matter, back then, if you lost a tiny bit of the televised image, it was way better than looking at garbage on the edges.

  OK, Great... But we live in an era of LCDs, Pixels, HDMI, etc. Frankly, in this era, I consider a display-purchase in terms of price-per-pixel. I sure-as-heck don't want my pixels to go wasted! (or, frankly, worse: mangled!)

  We also live in an era where "native-resolution" is *considerably* sharper than any scaled-resolution, even with the fancy new intra-pixel-anti-aliasing (or whatever the new buzz-word may be) available today... The fact is, there are X horizontal pixels, and Y vertical, on today's screens.

  Note that this varies *dramatically* from the old-school display-technologies, *cough* CRTs *cough*... which, frankly, were quite a bit more "analog". As long as the circuitry could handle it, it wouldn't appear much different if you displayed 300 rows or 350 rows... it'd just scale the image to the available screen.

  But, now, our era is such that displaying 1080 rows on an allegedly 1080-row display means first upscaling the image from 1080 to, say, 1120, then cropping off the upper 20 and lower 20 rows. This is called "overscanning." The idea is to mimic the old TV-technology of displaying stuff outside the TV's housing, so you won't see the "garbage" at the edges. Except, yahknow, we're in a digital era; if there *is* any "garbage" at those edges, it's because it was *placed* there, intentionally (e.g. for a while, there, that "garbage" in the end of the analog-era contained things like closed-captioning). Regardless, in the digital-era, it's *completely* irrelevant, and merely exists as a "feature" that most people *do not want*. 

  There's a bunch of math involved, but basically it boils down to a *much* less-crisp image, because whereas *without* this artificial "overscanning" *every* pixel transmitted (from the TV-station, or the video-file, or the *cough* COMPUTER *cough*) corresponded to a single pixel on the screen itself, instead, now, we have pixels which are one and some-fraction tall/wide. And how do we display some-fraction of a pixel? By anti-aliasing, or "intra-pixel" goofiness, which may [or may not] be so sophisticated as to consider each "pixel" and the physical position of its red, green, and blue "subpixels," and somehow creating a fractional-pixel (in which direction{s}?) by using a subset of RGB that may, in some case turn out to be GBR... [which, in fact, when displaying black text on a white background may appear as, e.g., Red-shift at the edges, but that's another topic. Although, now that I think about it, it's kinda ironic that in this digital era, we're essentially experiencing the bane of the analog-display-technologies *again*, e.g. NTSC="Never The Same Color," along with the whole reason people once preferred monochrome "hercules" displays over color CGA for text-editting, and more. We're experiencing it again! History Repeats! DESPITE THE TECHNOLOGY NOT TO!).

  Regardless, what it boils down to is that even when displaying a 1920x1080 image via HDMI (which is inherently digital) on a 1080p-native display, what you're really viewing is something more like 1880x1040 stretched across 1920x1080 pixels. The 20-pixel "border" on *all* sides is completely...

  Read more »

• Oldish Sony Vaio Laptop Sound Redirection

  Eric Hertz • 01/10/2017 at 09:39 • 0 comments

  This is for a Sony Vaio laptop, marked:

  PCG-7K1L
  VGN-FJ290
  

  The default Debian Jessie + Mate configuration for this guy's sound-card is such that the only place one can get sound-output is through the A/V output connector. Not through the speakers, not through the headphone-jack.

  (Interestingly, I didn't realize this was an A/V connector... I thought it was a line-out jack... BUT, it only output audio on the left channel, and sometimes the right channel would be noise, sounding a bit like 60Hz)

  But I wanted left/right, and speakers would be nice... so I did some searching.

  Most results said I need to recompile the kernel, some said you need to do some really gnarly stuff with alsa... But this is an old system, surely linux support for it should've been somewhat functional for some time...

  Finally I came across:

  https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1562396

  Which, if you scroll to the bottom describes the utility: "hdajackretask"

  Turns out, the only problem is that the BIOS isn't reporting (or the system isn't detecting) the output-mapping correctly.

  So, run "hdajackretask" and change "Pin 0x10" to "Line Out"

  Note that it does NOT work to change it to "Internal Speaker"
  

  Here are my notes:

  # Realtek ALC260
  
  # DEFAULTS:
  #  0x0f    "Green Headphone, Rear side"     -> Headphone
  #  0x10    "Internal Line Out, Mobile-In"   -> <not selected>
  #  0x12    "Pink Mic, Rear side"            -> Microphone
  #  0x13    "Internal Mic, Mobile-In"        -> Internal mic
  # PHYSICALLY:
  #  Yellow   (Composite?!)
  #  Red      Mic-in
  #  Black    Headphones
  #
  # Default settings results in sound ONLY going to yellow jack!
  #  (Left-headphone only)
  #  (Often results in noise, 60Hz-ish, on right)
  
  # OVERRIDE ATTEMPTS:
  #  0x10     -> "Headphone" -> Speakers + Yellow getting output
  #           -> "Internal Speaker" -> Yellow only
  #           -> "Internal Speaker (LFE)" -> Same
  #           -> "Internal Speaker (Back)" -> Same
  #                vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
  #           -> "Line out (Front)
  #                    Speakers + Yellow
  #                    Headphone (Black) Overrides Speakers
  #                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  
  # BEWARE:
  #  Mate's Sound Preferences
  #    -> Hardware
  #    -> Test Speakers
  #        NO EFFECT with Tests....
  

  
  

• command-line utilities DIFFER from BSD! What To Do???

  Eric Hertz • 12/03/2016 at 19:31 • 0 comments

  Update 12-4-16: some ideas how to be "safe" (at the bottom)
  

  Whoops...

  And here I thought I wrote all those scripts on my old Mac such that they'd be compatible with any unixish system I might use in the future...

  https://unix.stackexchange.com/questions/79355/what-are-the-main-differences-between-bsd-and-gnu-linux-userland

  OK, so now I've got some learnin' to do... and not because I was planning on working *on* a script, but because I was planning to *use* a script I'd written long ago... roughly... just to make a friggin' backup for a completely unrelated project, so I could actually *work* on that completely unrelated project.

  And, now, I'm a bit fearful maybe a bunch of such scripts I've been using for years may have had unexpected--and more importantly unnoticed--results on my comparatively-new linux systems... (in-use for about two years now).

  ----------
  

  Today's discovery: "stat" exists on both systems, but have entirely different arguments.

  On my Mac, years ago, I wrote a script containing the following:

  stat -t "%Y-%m-%d_%H.%M.%S,$timeArg" -f "%S$timeArg" "$file"

  This outputs a path/filename-safe string indicating the (selectable) modification/creation/etc. date of a file, in a human-readable format... Yahknow,

  2016-12-3_11.14.35,m

  ('m' indicating that I used the modification-date).
  

  (Since, yahknow, e.g. when copying files, or worse moving files from a broken-down system to a new system, sometimes you forget to do things like preserve creation-times, or worse the different systems don't actually track the various times of the files in the same manner/at all...)
  

  That same 'stat' line runs fine on a linux system, too... but with *ENTIRELY* different results.

  Now I've a "time-string" in my backup-filename that looks like:

  [input-filename] 3c83fbf27aaf3d25 255 ef53 4096 4096 59030720 4746332 1741968 15007744 13102124

  where, again, it should be:

  2016-12-3_11.14.35,m

  'man stat' on the (now dead) OSX apparently gives the following:
  

  https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/stat.1.html

  which differs somewhat dramatically from 'man stat' on the linux machine I'm using.

  Alright, now I'm fearful... what other utilities have I been making use of that have different arguments? What kind of unnoticed consequences have been percolating over the years...?

  ------------

  And, since I wrote these things already for BSD, apparently, I don't really want to *rewrite* them for linux... so, I suppose, how can I somehow safely detect which system it's running on, and reformat the calls accordingly? (And... am I going to have to worry about them changing the arguments in newer versions?)

  OY! That's a LOT of work ahead to make use of tools I've already been using for years.

  .........

  dammit, all I wanted to do was make a backup of an existing/functional project so I could get to work on improving it!

  -----------

  Update 12-4-16:

  I think the solution is not to use checks of which *system* I'm using, but to use checks of which *utility* I'm calling.

  E.G. For 'stat' on linux there's a --version argument...

  So, instead of calling 'stat' directly, maybe an intermediate script that calls 'stat' that runs something like:

  statVerString="stat (GNU coreutils) 8.23"
  
  blah=`stat --version | grep "$statVerString"`
  if [ "$?" != "0" ]
  then
     echo "$0 is only tested with: '$statVerString'"
     echo "Verify compatible arguments with 'stat $statArgs'"
     exit 1
  fi
  
  string=`stat $statArgs`
  
  if [ "$?" != "0" ]
  then
     echo "'stat $statArgs' failed with:"
     echo "$string"
     exit 1
  fi
  

  Then, I guess, next time I move my scripts to a new system (hey, what about something like busybox which, as I recall, has *entirely* different arguments for the sake of minimizing things) at least it'll warn me to verify the arguments will work before executing with possibly completely unnoticed consequences.

  And, I suppose, it would be wise to include a detailed listing of what each argument does in the comments... since... like last time, I didn't have the option to run 'man stat' on...

  Read more »

• geda-pcb and Debian Jessie

  Eric Hertz • 11/22/2016 at 00:43 • 0 comments

  Worked-ish... but had issues...

  E.G. Running a Design Rules Check would find errors, but in the window where it shows a thumbnail of the error, the thumbnail would be little more than the background-color.

  E.G.2. Double-clicking the error is supposed to send your cursor to the location of the error, and highlight the offending thingamajigs, instead it appeared to always move the cursor to the middle of the top of the board... Nothing to see, no offending-thingamajig-coloration.

  (Maybe somehow related to its originally having been built with the assumption I was using GNOME3, but downgraded because my second video-card doesn't support xrandr, or something?)
  ----------

  A fresh build has fixed these problems...

  $ git clone git://git.geda-project.org/pcb.git
  $ cd pcb
  $ ./autogen.sh
  ....
  ./autogen.sh: 1: ./autogen.sh: intltoolize: not found
  

  As I recall, I did an install of 'intltool' to fix this.

  $ ./autogen.sh
  ...
  $ ./configure --enable-gl --enable-dbus=no --with-x --disable-doc
  

  --disable-doc because apparently texlive isn't installed and is a 300+MB download
  Not sure about dbus, but it complained about its missing. My MacOS system used it, but apparently it's not required, so whatevs.
  --enable-gl and --with-x because... well it's graphics, and the problem was graphics-related... and it worked this way on my MacOS 10.5.8 machine, way-back-when

  
  You'll likely have to run ./configure *several* times, as many of the dependencies are not already installed...

  Thankfully the messages are quite-informative, Search-fu may help, if you can't figure out what you need... but in most cases you need '<whatever>-dev' E.G. The latest (and amongst the least-intuitive) was:

  Cannot find gdlib-config.
  Make sure it is installed and in your PATH.
  gdlib-config is part of the GD library available from www.boutell.com/gd.
  This is needed for the png HID.  I will look for libgd anyway and maybe
  you will get lucky.
  
  checking for main in -lgd... no
  configure: error: You have requested gcode, nelma, or png HIDs  but -lgd could not be found

  As I recall, I did an install of libgd-dev... yeah it differs in name quite a bit, but I think you can get the drift.

  If not, feel free to ask.

  $ make
  $ sudo make install

  Bam!

  ---------

  There were a bunch of other quirks, too... As I recall, the keys didn't do what they were supposed to, e.g. "u" should undo, but it didn't. Now it does.

  -------

  And, for a moment-of-rant...

  I find it hilarious that I can move around a PCB with all these renderings, zooming, and scrolling, on my second-monitor with nary a speed-issue... Yet I can't scroll a small listing of files in a file-browser window without at least half-a-second between each refresh. Nor spin my scroll-wheel five ticks in a friggin' word-processor document without getting caught in literally *seconds* of refreshes.

  We're not talking about a friggin' ancient single frame-buffer ISA video-card from the Win3.1 era, here... (And, even if we were, as I recall ISA/VESA graphics-cards could be updated fast enough for full-screen *movies* back then). This was a top of the line *industry-grade* (not *consumer-grade*) 3D-renderer of its time, 32MB should be *plenty* for these things.

  </rant>

  <rant 2>

  No, I will not while away my time learning a new PCB-application that changes every three weeks. That's utterly ridiculous. This one has worked fine for me for nearly a decade.

  </rant>
  

• USB Parallel Port adapter, low-level coding usblp.c

  Eric Hertz • 08/06/2016 at 21:39 • 16 comments

  Update Jan. 2019: Apologies, this was written with #sdramThingZero - 133MS/s 32-bit Logic Analyzer in-mind, and therefore is *way* overcomplicated for most projects. If you just want to write some outputs (blink LEDs, control a text-LCD, etc.) please check out the link in the comments. You could probably control a 7-segment LED with a little wiring and "echo x > /dev/usb/lp0". Input, however, may be a little more difficult, I don't know.

  However, brief note as to the main point, here... the parallel port may've been scanned by linux for attached-devices, which may leave your parallel port in an unknown mode.

  This is about checking and changing the parallel port mode. 

  (Similar to setting the baud-rate of a serial port.)

  --------

  So, you've got a USB-to-Parallel adapter that you'd like to use for a project (not a printer)...

  (Hey, I'm no expert, here... so take this as the ramblings of a newb):
  

  First: There are Major Limitations... These adapters are *nothing* like the ol' Parallel Port built into old motherboards or on ISA cards... So, don't be getting high-hopes about bit-banging this thing. (There's lots of info about this all 'round the interwebs).

  BUT: If your project *can* work within those limitations, then you'll first need to figure out how to set the adapter into the right mode...

  So, what're those limitations?

  I'm no expert, here, but it seems there are three "modes" these things can work in...

  1. Unidirectional
  2. EPP/ECP compatible
  3. IEEE-1284 compatible

  1: Unidirectional -- Might work for your project... If *timing* isn't particularly-sensitive, you should have access to the 8-data-bits as outputs, and 3 control lines as inputs (if I understand correctly)... It could probably be done-ish... but nothing like the level of functionality the ol' ISA cards had.

  3. IEEE-1284 -- This guy looks pretty gnarly and basically requires a microcontroller on the "peripheral"-side to handle the protocol. There ain't much to bit-bang with this method, unless, maybe, you're a truly-1337 haxor.

  ---

  2. EPP/ECP -- This is the one I'm looking at.

  So this guy doesn't look *so* complicated. And, in fact, it looks like it might be darn-near exactly the sort of interface I need for #sdramThingZero - 133MS/s 32-bit Logic Analyzer, and really not that much different from, say, the interface on an HD44780 Character-LCD.

  The basic idea is to use the Data I/Os bidirectionally. This gets a bit more complicated with the whole USB thing, since you've got to send a request for a certain number of *reads* or *writes*... which means, for *reads*, your peripheral has to be able to respond with acknowledgements... (I think I can get around that with an OR gate, in my case)... and has to set-up the next byte to be transmitted, etc.

  ---

  Anyways, sidetracked. The point is, when you plug in the USB-parallel adapter, it doesn't look to the computer like merely a parallel port (like a USB-serial adapter looks like nothing more than a serial port)... instead, Linux tries to look for a *printer* connected to that parallel port.

  In a high-level sense, it makes sense... it's just another bus; parallel, USB, PCI, SCSI, whatever...

  But that means it's got a procedure for looking for attached devices, and when it can't find one, it might just leave your new "parallel port" in a mode you don't want...

  So, there're some settings you might want to send your new "parallel port"... but how do you do that when all you've got is /dev/usb/lp0, fopen(), fclose(), fread(), and fwrite()...? Yeah, no... ioctl() is the way to go.

  That's, basically, the same thing used for e.g. setting a serial port's baud-rate... you can't do that by just sending some ASCII characters to /dev/ttyUSB0, you have to use ioctl(). 

  (or use a utility like stty or setserial, which calls ioctl() as-appropriate. I have yet to find a similar utility for parallel-ports.)

  OK, then... But this USB-adapter needs a mode-setting, and with my search-fu there's...

  Read more »

• Oldish Sony Vaio Laptop + Debian Jessie + USB-booting when the BIOS doesnt support it

  Eric Hertz • 08/03/2016 at 12:09 • 3 comments

  Alright! My first laptop in nearly 2 years! (I've been sitting at the ol' desktop since the old one suffered the GPU-deballing fate).

  The cat *seems* to be quite happy about it... but now she's not. You know cats...

  So, here we are... I finally have a laptop about the equivalent of (actually slightly lower-spec'd than) the one I invested a Hefty Fortune into over a decade ago, and expected to last me a good decade+ (but didn't due to stupidity).

  So, here we are... A Laptop! 2006, no less! Movin' on up!

  ---

  So, here's the deal... I'll make it real quick, then go into details, I guess.

  Blacklist BOTH: 'sonypi' AND 'sony-laptop' modules.

  ---

  OK, I can't recall *how* I determined this path, but this is the path I took:

  First of all, the debian Jessie: 8.5.0 live-boot was flakey, to say the least. But I recalled the same from my desktop (and an older version of Jessie, as well as Wheezy?) The end-result being: *install* seems to work-ish, but live-boot is questionable.

  So, that's the first bit.

  Then, from there, booting seemed to stop after fsck ran... There was a weird message about an unhandled interrupt, but that wasn't the problem. Oh yeah "nobody cares" no joke, that's what it said.

  Oh, wait, there was a step before that... USB-Booting... Nogo. And I've only got a handful of blank DVDs...

  Most of those are now coasters. But before wasting *them all* I had a brilliant idea... Certainly someone has come up with a boot-disc/k that can load-up a menu for booting from e.g. USB even on systems which don't have BIOS support for it... right?

  YEP!

  I mean, I know that technology's progressing and all that jazz, but this "new" (to me) laptop is in damned-near pristine condition, despite being over a decade old... This thing's still useful, and if logic serves me, there must be a million others out there in equally useful condition (things that've been sitting in server-closets as little more than remote-desktop machines for those times) if people would just put some time into it... (two days, now... yeah, it'd be cheaper, hour-wise, to buy a new one... are you really "green"? 'cause the carbon-footprint of building a new system, no matter how much faster and more energy-efficient, *far* outweighs the carbon-footprint of a couple days of work and probably *all* the inefficiency of this CPU's remaining lifetime, running at 100% the whole time...)

  Anyways, some people have actually thought about this, or are lazy, or cheap, or Luddites, or something. Thank God For Them.

  YES: You *CAN* boot from a USB thumb-drive on a system which doesn't support booting from USB... https://www.plop.at/en/bootmanagers.html
  

  So, burn ONE CD (or even a floppy) with that image, and quit wasting DVDs when you could be using thumb-drives. (BTW: my "thumb-drive" is my camera's SD-card and an adapter... Gotta erase this thing when I'm done to use my camera again. Heaven forbid).
  

  Alllllright... where we at...?

  Download that shizzle, and more importantly, if you find it useful and you make even $5 more than I make in a month (and I dang-near guarantee that's the case, in consideration of local cost-of-living, etc.) send that bloke $5 for all his hard work so the next version doesn't contain a virus...

  Alright, where we at...?
  OK, so this laptop... it's got some issues, it probably needs some resoldering somewhere, but in general, it's running. I have to pull the power/battery every so often before it'll boot. But I'm writing on it now, so obviously it's not *so* bad... Sooner or later, maybe I'll open it up and see if the BIOS-battery has died...

  Alright, where we at...?

  Oh yeah, so, I finally booted Debian Jessie's (MATE! Not GNOME!) installer from the live-image (but wasn't able to get it to live-boot), and did the full installation... and upon the first boot was met with two messages.

  A) Some sort of interrupt that "nobody cares" about.

  B) fsck did its check, and it stopped there.

  Dead-frozen... Even CTRL-ALT-DEL did nothing.

  So, some searching (and, if you know me, then you know my search-fu has...

  Read more »

View all 8 project logs