ter than your 10+ years stuff. If i don't use them, they will be trashed a nyway. First, they are made unusable with Vista, but they are great for Lin ux router. The 10" screen and resolutions are too small for real work.
to drop into a backpack and pull out again on the train.
Problem is the low resolution of 10" 1024x. My other machines are 11" 1300 x. The higher resolution makes them much better.
and they are light enough not to be really noticable while walking around a city (although I wouldn't carry one on a long distance day walk. :-))
Which one? I think they have 8.9", 10.1" and 11.6". Haven't check the res olutions, but the 11" is probably fine.
I would not want to use it all day, but it's ok while on the train for up to about 90 minutes.
8.9 inch, resolution 1024x600, model version ZG5.
For dropping into a backpack, it's an ideal size as I would not want to be lugging a bigger version around while also having packed quite a bit of other stuff as well.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
My router wasn't 'old' in 2005, it was top-of-the-line (for consumer kit anyway, it replaced a power hungry PC which is what got used for routing in the late 90s/early-2000s: Netgear etc boxes came along later)
In 2012 it was 'old', but it was a case of "I fly at 6am tomorrow, I need something right away to run my networking stuff". Sometimes waiting for the post is too long, and the selection of devices that are available retail locally isn't good enough.
Curiously enough, I had to buy a new router recently and noticed that in 10 years there hasn't been a lot of improvement: many of the devices out there have better CPUs, but still have 8MB RAM/4MB flash and at the same kind of price point they sold for a decade ago. There's a few more 'high end' routers that have more RAM and USB than there used to be, but you still have to pick through the minefield to find them (only a subset will run OpenWRT for instance).
So you're running on an old netbook? That doesn't sound like 'wasting resources' - like my router it was going spare. But they're different things: I doubt your netbook's wifi would manage a whole city block (which my router didn't quite do either, but would have been handy).
re power than COTS router, perhaps 5W average. And the netbook cost me les s than $50, becasuse of a cracked LCD screen.
sources' - like my router it was going spare. But they're different things : I doubt your netbook's wifi would manage a whole city block (which my rou ter didn't quite do either, but would have been handy).
I think i could, in theory. ;-) With three devices connected, the Wifi ser ver proc (hostapd) never get much more than 1% usage. So, it could support at least 100 devices. Perhaps someday, i'll try it and see how many can c onnect to it in public.
The argument against using PC/laptops vs. COT routers has been price and po wer consumption. These old netbooks can beat/match COT routers with around $50 and 5W.
However, running with the hard drive would double the power consumption to at least 10W. It is better to have enough memory and run it diskless.
I'm a little late into this discussion but since we discussed this at length last time around and I still remember a lot of the context I'll throw in my two cents...
I take it we're still talking about Neoware (or similar) terminals here? The specs mentioned elsewhere seem to fit that assumption. If we're talking about something going under a dresser (on a carpet?) I'd hope it's passively cooled to keep the fluff out as well as keeping the noise down for fit-and-forget devices such as this.
On a similar vein I've noticed that the cooling on those kinds of devices tends to be a lot better when vertically orientated - obviously I can't speak for your particular circumstances but I'd stop and think whether it can be orientated upright in another out of the way location - say understairs or airing cupboard, or even wall mounted _behind_ the dresser - with passive cooling you really need to help things out as much as possible to maximise useful life.
As for your substantive question a microdrive style unit (i.e. CF interface HDD) is the obvious solution - your capacity is limited to around 4 or 5GB but that's room for a full NetBSD install and plenty of packages, more than enough for basic services. However, I do have a few words of caution there. Firstly is one of simple interoperability - I tried soldering on a CF socket to the unused mounting locations on MY Neoware project that we talked about last time, along with adding a couple of nearby jumper headers that turned out to control master/slave selection. Works fine with a flash card but completely fails to recognise the microdrive I fitted.
I don't know exactly why that is - it obviously fits in the socket and the Neoware (CA21 IIRC) provides the 5V power it needs as opposed to 3.3V. There's probably some hack I could make to force it to work but I never did experiment that far. However, I did have success sticking it in a USB enclosure and running from that, which is what I'll base the rest of my comments on.
The next point is that they seem to be understandably power optimised in a very aggressive manner - they spin down after perhaps as little as five SECONDS inactivity. For something like a root filesystem that adds a considerable amount of latency since the disk needs to spin up first for every round of activity. They also seem to autopark quite quickly - again that's eminently sensible for the intended use case but makes them quite "clicky" in operation, which may not be desirable from an acoustic standpoint. Nowadays I keep that to one side as an emergency freestanding boot device, i.e. something that works properly even if DNS, NIS or whatever is down.
As such I probably wouldn't recommend one which raises the question of alternatives. USB drives are cheap enough these days that even reasonably generous sized drives can be considered consumable - only last week I bought a pair of of 16GB drives for a combined
economics. I've never done it but I don't see why you couldn't run a pair in RAID 1 configuration using RAIDframe. You'll need to devise some method of error reporting though to alert you when one drive is failing - syslog forwarding would be a start but be honest, how often do you actually read your logs? Perhaps a cron job grepping dmesg for RAIDframe messages and emailing anything it finds would solve that problem. You may need to add a bus-powered hub to get the ports and/or physical space you need, but again those cost next to nothing these days if you don't already have one lying around.
One final point regarding emergency access - have you considered a serial console? It seems a far better solution than keeping keyboard, mouse and monitor handy just in case. Since you're probably limited to 100Mbit ethernet anyway you wouldn't be losing anything by running both LAN and console over the same lead with voice/data splitters at each end.
The old box was a Wyse WT8440XL (~400MHz/256MB) which actually has provisions for a laptop drive -- in addition to a laptop CD (*and* the DoC). Worked for many years. But, draws a fair bit of power (it's very warm; power supply is 5V@7A 12V@1A,-12V@0.1A,5VSB@0.5A), is reasonably large *and* has a whopping big power brick (*9* pin circular DIN power connector)!
[Location for the CD drive -- and laptop disc behind/below it -- can be seen where the CF card is present in the above]
I have several CA10's but they are essentially the same size as the WYSE and seem like overkill (~1GHz/1-2GB). I've added a 100G drive to one of them and had no problems with it -- but prefer not having *that* running 24/7 (I think it probably draws ~30W when running -- pretty "rich" for a box that is intended to do very little!)
Likewise, some CA5's -- but they are a bit tighter to cram a disk inside. OTOH, they don't require an external power brick!
I came across a T5530 in my goody box. About the same volume as the CA5 but much faster. I.e., about half the size of the Wyse and more performant (in terms of MIPS, USB ports, etc.)
I'm on a "downsizing binge" so toss the T5530 *or* keep it and toss something *else*! :>
The 8440 was pretty happy under the dresser. It was a good location as it was adjacent to a small UPS (intended primarily for it!) as well as easy to slide a 9" keyboard atop the case for those times when I needed to "talk to it" ("shutdown -p now" -- easily typed even w/o a monitor to observe! :> )
[Fast forwarding ahead... it has been tossed (I pulled the laptop CD, 2.5" disc and the very low profile 128MB DIMMs). I managed to squeeze a 2.5" drive into the T5530 -- barely -- and *it* now is located UPRIGHT on the far side of the dresser (adjacent to one of my Phasers) where I can easily get at it (I'm too old to be crawling under dressers to talk to kit! :< )]
Each of my Neowares (as well as all of the boxes that I've discussed here) has a 44 pin connector on the main board already. Many of them have DoM's installed.
One of my CA10's has a PCMCIA slot populated on the main board.
Ouch! I hadn't considered that! I've had laptop drives spin down "too often" -- but never anywhere near that quickly! I.e., you'd have to write a daemon to just keep tickling the drive to keep it spun up!
Makes sense. *That* is the problem -- I rely on this box for
*everything*. And, have all my other services configured to assume
*it's* services are always available (e.g., reverse lookups on IP's for telnet/ftp/etc. sessions on other boxes -- as well as resolving the names of the ftp host I'm trying to contact!)
For example, when I took the WT8440XL down and started building a disk for the T5530 (mounting the drive in another NetBSD box and copying the files over "at bus speed" instead of "over the wire"), I was puzzled as to why I couldn't xdm to that (headless) NetBSD box! Even moreso when I couldn't *telnet* to it!! Or *ping* it!! :-/
("Oh, crap! Off the top of my head, what's the IP of 'Tennessee'?")
T5530 has provisions for two *internal* USB devices (conveniently limited to the size of thumb drives) in addition to the externally accessible USB ports.
My current plan (now that I am not time constrained by "needing an answer, NOW!") is to move the system onto *a* thumb drive (I assume I can just treat the thumb drive as any other "disk"? I.e., do the fdisk/disklabel/newfs dance) and leave swap on the rotating media (i.e., until I am sure the USB device can be mounted R/O).
Then, replace the disk with a CF card -- presumably it would be faster than a thumb drive (?) in random access (e.g., as swap).
Then, try replacing the CF card with a *second* thumb drive that is JUST for swap.
[Does this make sense?]
The tricky part will be determining when the swap device is no longer reliable -- and trying to painlessly recover from that. I.e., I can't just modify /etc/rc to fall back to key services in the absence of swap -- as I'll never really be able to tell if swap is "dead"!
Anything "important" gets mailed by services -- of course, this same box acts as my POP/SMTP service so I have to rely on it being operational to figure out what *other* things aren't working!
I'd prefer NOT having to rely on an external box. While the T5530's brick is much smaller than the WT8440XL's, it's still "yet another box" (The CA5's would have been ideal -- but they are dog slow and hard to cram anything inside). Having to add an external drive just means more clutter.
[The T5530 is delightfully small when contrasted to the Wyse box. And, reasonably speedy -- a fresh kernel build from "make config" is just two or three minutes!]
A couple of my boxes have *only* a serial console -- no video hardware at all! Each time I boot one of them, I (almost literally) hold my breath until it goes multiuser (and I can telnet into it). I keep a small laptop for use with a terminal emulator in those cases (the serial ports on other machines from which I might tip(1) are hard to access -- as are the serial ports on the headless boxes).
Each serial console box has a permanently attached serial cable labeled with the protocol requirements -- data rate, character format, account name/password, etc. (e.g., the Netra needs the serial console *pre*boot, at times!)
Bottom line, the serial consoles just leave me with one more source of anxiety. Instead, I keep a 7" monitor and 9" keyboard in a small bag and carry them to whichever machine is *operating* "headless" (but capable of handling a monitor!) as the need arises -- as I will for the T5530.
(sigh) Solution is to continue shedding kit! E.g., I've got ~24 drops in the office, alone!
Next, I'll sort out how to PXE boot an X-server on the CA10's and try to get rid of the "email/web" type machines around here (hoping for a more robust/secure implementation!)
From memory that'll be a VIA Chrome chip in which case no. At least that's the way it was with the VIA EPIA boards of that era which seem to be a productised reference design, in that there's a 1:1 equivalence in support chips between the Neoware mainboards and the equivalent EPIA. It's a little more than mere convenience in that it does generate a digital out, but the displays are clones of each other right down to signal timing.
I'll reply to your other post tomorrow, it's getting pretty late here now.
I suspect the wifi from the little patch antenna mounted in the screen might not do so well in terms of signal strength compared to something with an external antenna.
Bit tricky to nail a netbook to the wall. And the 'locals' may take an unhealthy interest when they see a 'free' laptop. Like I said, this was a 'hostile' environment. Did I mention ambient temperatures of 50degC? That's where power consumption really bites, because cooling just isn't there.
server proc (hostapd) never get much more than 1% usage. So, it could sup port at least 100 devices. Perhaps someday, i'll try it and see how many c an connect to it in public.
ght not do so well in terms of signal strength compared to something with a n external antenna.
To cover a large area, we would need external USB adapters with antenna any way. They are less than $10 ea. We would also need to use multiple channe ls.
d power consumption. These old netbooks can beat/match COT routers with ar ound $50 and 5W.
nhealthy interest when they see a 'free' laptop. Like I said, this was a ' hostile' environment. Did I mention ambient temperatures of 50degC? That's where power consumption really bites, because cooling just isn't there.
It could be hidden in a box mounted up in wall, tree or post, as long as th ere is some power (even solar could work). Or it could be mounted inside a car, with the webcam "seeing" passing-by as well. With the LCD screen and hard drive off, the netbook and power plug are cool to the touch. I think it draws less than 5W average.
Hmmm... dmesg of a kernel I built for the box with the disk drive (not the T5530 that was the original subject of this thread but a CA10) -- linewrap unavoidable (blame the driver authors! :> ):
NetBSD 3.1 (BASTION) #1: Wed Aug 27 16:11:02 MST 2014 snipped-for-privacy@Bastion.XXXX.XXX:/usr/src/sys/arch/i386/compile/BASTION total memory = 1015 MB avail memory = 989 MB BIOS32 rev. 0 found at 0xfb3a0 PCI BIOS rev. 2.1 found at 0xfb3f0 pcibios: config mechanism [1][x], special cycles [1][x], last bus 3 PCI IRQ Routing Table rev. 1.0 found at 0xfdf00, size 128 bytes (6 entries) PCI Interrupt Router at 000:17:0 (VIA Technologies VT82C596A PCI-ISA Bridge compatible) PCI Exclusive IRQs: 5 11 12 15 mainbus0 (root) cpu0 at mainbus0: (uniprocessor) cpu0: VIA C3 Nehemiah (686-class), 1000.48 MHz, id 0x698 cpu0: features 381b03f cpu0: features 381b03f cpu0: features 381b03f cpu0: "VIA Nehemiah" cpu0: I-cache 64 KB 32B/line 2-way, D-cache 64 KB 32B/line 2-way cpu0: L2 cache 64 KB 32B/line 8-way cpu0: ITLB 128 4 KB entries 8-way cpu0: DTLB 128 4 KB entries 8-way cpu0: 8 page colors pci0 at mainbus0 bus 0: configuration mode 1 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok pchb0 at pci0 dev 0 function 0 pchb0: VIA Technologies VT8623 (Apollo CLE266) CPU-PCI Bridge (rev. 0x00) agp0 at pchb0: aperture at 0xe4000000, size 0x10000000 ppb0 at pci0 dev 1 function 0: VIA Technologies VT8633 (Apollo Pro 266) CPU-AGP Bridge (rev. 0x00) pci1 at ppb0 bus 1 pci1: i/o space, memory space enabled vga0 at pci1 dev 0 function 0: VIA Technologies VT8623 (Apollo CLE266) VGA Controller (rev. 0x03) wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation) wsmux1: connecting to wsdisplay0 wsdisplay0: screen 1-3 added (80x25, vt100 emulation) ppb1 at pci0 dev 8 function 0: Intel S21152BB PCI-PCI Bridge (rev. 0x00) pci2 at ppb1 bus 2 pci2: i/o space, memory space enabled, rd/line, wr/inv ok fxp0 at pci2 dev 0 function 0: i82550 Ethernet, rev 16 fxp0: interrupting at irq 15 fxp0: May need receiver lock-up workaround fxp0: Ethernet address 00:00:50:0f:0e:1b ukphy0 at fxp0 phy 1: Generic IEEE 802.3u media interface ukphy0: i82555 10/100 media interface (OUI 0x005500, model 0x0015), rev. 4 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1 at pci2 dev 1 function 0: i82550 Ethernet, rev 16 fxp1: interrupting at irq 11 fxp1: May need receiver lock-up workaround fxp1: Ethernet address 00:00:50:0f:0e:1c ukphy1 at fxp1 phy 1: Generic IEEE 802.3u media interface ukphy1: i82555 10/100 media interface (OUI 0x005500, model 0x0015), rev. 4 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp2 at pci2 dev 2 function 0: i82550 Ethernet, rev 16 fxp2: interrupting at irq 5 fxp2: May need receiver lock-up workaround fxp2: Ethernet address 00:00:50:0f:0e:1d ukphy2 at fxp2 phy 1: Generic IEEE 802.3u media interface ukphy2: i82555 10/100 media interface (OUI 0x005500, model 0x0015), rev. 4 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp3 at pci2 dev 3 function 0: i82550 Ethernet, rev 16 fxp3: interrupting at irq 12 fxp3: May need receiver lock-up workaround fxp3: Ethernet address 00:00:50:0f:0e:1e ukphy3 at fxp3 phy 1: Generic IEEE 802.3u media interface ukphy3: i82555 10/100 media interface (OUI 0x005500, model 0x0015), rev. 4 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto cbb0 at pci0 dev 9 function 0: Texas Instruments PCI1510 PCI-CardBus Bridge (rev. 0x00) uhci0 at pci0 dev 16 function 0: VIA Technologies VT83C572 USB Controller (rev. 0x80) uhci0: interrupting at irq 15 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: VIA Technologies UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 16 function 1: VIA Technologies VT83C572 USB Controller (rev. 0x80) uhci1: interrupting at irq 11 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 uhub1: VIA Technologies UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2 at pci0 dev 16 function 2: VIA Technologies VT83C572 USB Controller (rev. 0x80) uhci2: interrupting at irq 5 usb2 at uhci2: USB revision 1.0 uhub2 at usb2 uhub2: VIA Technologies UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0 at pci0 dev 16 function 3: VIA Technologies VT8237 EHCI USB Controller (rev. 0x82) ehci0: interrupting at irq 12 ehci0: BIOS has given up ownership ehci0: EHCI version 1.0 ehci0: companion controllers, 2 ports each: uhci0 uhci1 uhci2 usb3 at ehci0: USB revision 2.0 uhub3 at usb3 uhub3: VIA Technologie EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: single transaction translator uhub3: 6 ports with 6 removable, self powered pcib0 at pci0 dev 17 function 0 pcib0: VIA Technologies VT8235 (Apollo KT400) PCI-ISA Bridge (rev. 0x00) viaide0 at pci0 dev 17 function 1 viaide0: VIA Technologies VT8235 ATA133 controller viaide0: bus-master DMA support present viaide0: primary channel configured to compatibility mode viaide0: primary channel interrupting at irq 14 atabus0 at viaide0 channel 0 viaide0: secondary channel configured to compatibility mode viaide0: secondary channel ignored (disabled) auvia0 at pci0 dev 17 function 5: VIA Technologies VT8235 AC'97 Audio (rev 0x50) auvia0: interrupting at irq 5 auvia0: ac97: VIA Technologies VT1612A codec; headphone, 18 bit DAC, 18 bit ADC, KS Waves 3D auvia0: ac97: ext id 201 audio0 at auvia0: full duplex, mmap, independent vr0 at pci0 dev 18 function 0: VIA VT6102 (Rhine II) 10/100 Ethernet vr0: interrupting at irq 15 vr0: Ethernet address: 00:e0:c5:59:27:98 ukphy4 at vr0 phy 1: Generic IEEE 802.3u media interface ukphy4: OUI 0x0002c6, model 0x0032, rev. 8 ukphy4: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto cbb0: interrupting at irq 15 cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 3 device 0 pcmcia0 at cardslot0 isa0 at pcib0 com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo pckbc0 at isa0 port 0x60-0x64 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 mpu0 at isa0 port 0x330-0x331 irq 9 midi0 at mpu0: Roland MPU-401 MIDI UART joy0 at isa0 port 0x201 joy0: joystick not connected pcppi0 at isa0 port 0x61 midi1 at pcppi0: PC speaker spkr0 at pcppi0 sysbeep0 at pcppi0 isapnp0 at isa0 port 0x279: ISA Plug 'n Play device support npx0 at isa0 port 0xf0-0xff: using exception 16 isapnp0: no ISA Plug 'n Play devices found apm0 at mainbus0: Power Management spec V1.2 apm0: A/C state: on apm0: battery charge state: no battery Kernelized RAIDframe activated wd0 at atabus0 drive 0: wd0: drive supports 16-sector PIO transfers, LBA addressing wd0: 95396 MB, 193821 cyl, 16 head, 63 sec, 512 bytes/sect x 195371568 sectors wd0: 32-bit data port wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) wd0(viaide0:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using DMA) boot device: wd0 root on wd0a dumps on wd0b root file system type: ffs wsdisplay0: screen 4 added (80x25, vt100 emulation) Accounting started
[N.B. fxp* are an add-on card; all other devices are native]
Note "VIA Technologies VT8623 (Apollo CLE266)". From some quick doc checks, it looks like this supports dual monitors with two independent contents, refresh rates and resolutions (in practice, I run identical monitors so rates and resolutions can remain the same).
I'll have to see if the X server will support Xinerama on this chipset or if I will have to treat them as two different (logical) display devices (i.e., :0 and :1).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.