Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #18060 > unrolled thread
| Started by | Don Y <this@is.not.me.com> |
|---|---|
| First post | 2014-09-17 00:46 -0700 |
| Last post | 2014-10-10 09:53 +0000 |
| Articles | 20 on this page of 230 — 31 participants |
Back to article view | Back to comp.arch.embedded
Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-17 00:46 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-17 04:05 -0400
Re: Intel Atom: pros/cons/hazzards? dplatt@coop.radagast.org (David Platt) - 2014-09-17 11:09 -0700
Re: Intel Atom: pros/cons/hazzards? Les Cargill <lcargill99@comcast.com> - 2014-09-17 22:52 -0500
Re: Intel Atom: pros/cons/hazzards? mroberds@att.net - 2014-09-17 08:21 +0000
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-17 02:00 -0700
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-17 13:08 +0200
Re: Intel Atom: pros/cons/hazzards? JW <none@dev.null> - 2014-09-17 08:24 -0400
Re: Intel Atom: pros/cons/hazzards? mroberds@att.net - 2014-09-17 21:44 +0000
Re: Intel Atom: pros/cons/hazzards? dplatt@coop.radagast.org (David Platt) - 2014-09-17 15:04 -0700
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-18 00:28 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-18 03:41 -0400
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-18 03:31 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-18 18:12 -0400
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-18 15:53 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-18 19:22 -0400
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-18 17:18 -0700
Re: Intel Atom: pros/cons/hazzards? josephkk <joseph_barrett@sbcglobal.net> - 2014-09-18 21:16 -0700
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-18 21:44 -0700
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-19 09:19 +0200
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-19 01:36 -0700
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-19 11:53 +0200
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-19 03:10 -0700
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-19 13:02 +0200
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-19 04:26 -0700
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-19 13:50 +0200
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-19 10:16 -0700
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-20 16:42 +0200
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-20 12:19 -0700
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-20 21:58 +0200
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-20 13:33 -0700
Re: Intel Atom: pros/cons/hazzards? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-09-20 23:00 +0000
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-20 16:14 -0700
Re: Intel Atom: pros/cons/hazzards? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-09-21 02:12 +0000
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-20 20:05 -0700
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-21 12:45 +0200
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-20 16:34 -0400
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-20 13:41 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-20 17:29 -0400
Re: Intel Atom: pros/cons/hazzards? Dombo <dombo@disposable.invalid> - 2014-09-21 00:12 +0200
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-20 19:01 -0400
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-20 16:17 -0700
Re: Intel Atom: pros/cons/hazzards? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-09-21 02:17 +0000
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-20 22:27 -0400
Re: Intel Atom: pros/cons/hazzards? Grant Edwards <invalid@invalid.invalid> - 2014-09-21 13:25 +0000
Re: Intel Atom: pros/cons/hazzards? Dombo <dombo@disposable.invalid> - 2014-09-21 15:56 +0200
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-21 18:19 +0200
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-21 09:37 -0700
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-21 14:22 -0700
Re: Intel Atom: pros/cons/hazzards? Grant Edwards <invalid@invalid.invalid> - 2014-09-21 23:13 +0000
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-21 14:20 -0700
Re: Intel Atom: pros/cons/hazzards? Grant Edwards <invalid@invalid.invalid> - 2014-09-21 23:15 +0000
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-21 20:20 -0700
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-20 16:09 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-20 22:05 -0400
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-20 23:25 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-21 03:28 -0400
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-21 01:27 -0700
Re: Intel Atom: pros/cons/hazzards? Dombo <dombo@disposable.invalid> - 2014-09-21 14:20 +0200
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-21 13:09 +0200
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-21 12:06 -0700
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-22 09:55 +0200
Re: Intel Atom: pros/cons/hazzards? Dombo <dombo@disposable.invalid> - 2014-09-20 23:54 +0200
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-20 15:46 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-20 19:09 -0400
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-20 16:29 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-20 22:11 -0400
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-20 20:40 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-21 00:56 -0400
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-20 23:40 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-21 03:35 -0400
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-21 01:47 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-21 07:33 -0400
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-21 11:56 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-21 20:32 -0400
Re: Intel Atom: pros/cons/hazzards? Clifford Heath <no.spam@please.net> - 2014-09-22 11:03 +1000
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-21 18:18 -0700
Re: Intel Atom: pros/cons/hazzards? Clifford Heath <no.spam@please.net> - 2014-09-22 11:53 +1000
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-21 19:05 -0700
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-21 19:05 -0700
Re: Intel Atom: pros/cons/hazzards? krw@attt.bizz - 2014-09-21 11:50 -0400
Re: Intel Atom: pros/cons/hazzards? Jeff Liebermann <jeffl@cruzio.com> - 2014-09-21 18:50 -0700
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-21 20:09 -0700
Re: Intel Atom: pros/cons/hazzards? Jeff Liebermann <jeffl@cruzio.com> - 2014-09-21 21:25 -0700
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-21 22:12 -0700
Re: Intel Atom: pros/cons/hazzards? Robert Wessel <robertwessel2@yahoo.com> - 2014-09-23 09:38 -0500
Re: Intel Atom: pros/cons/hazzards? Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-09-22 10:15 +0100
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 04:59 -0700
Re: Intel Atom: pros/cons/hazzards? krw@attt.bizz - 2014-09-22 15:38 -0400
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-22 10:02 +0200
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 01:44 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-22 05:25 -0400
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-22 12:44 +0200
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 04:33 -0700
Re: Intel Atom: pros/cons/hazzards? Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-09-22 13:00 +0100
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 05:02 -0700
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-22 15:19 +0200
Re: Intel Atom: pros/cons/hazzards? Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-09-22 14:35 +0100
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 07:55 -0700
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-22 17:35 +0200
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 10:06 -0700
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-22 10:25 -0700
Re: Intel Atom: pros/cons/hazzards? Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-09-22 19:48 +0200
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-22 20:46 +0200
Re: Intel Atom: pros/cons/hazzards? "Michael A. Terrell" <mike.terrell@earthlink.net> - 2014-10-08 12:34 -0400
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-10-08 13:10 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-10-08 17:31 -0400
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-10-08 14:53 -0700
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-10-08 15:06 -0700
Re: Intel Atom: pros/cons/hazzards? Stefan Reuther <stefan.news@arcor.de> - 2014-10-09 19:09 +0200
Re: Intel Atom: pros/cons/hazzards? Robert Wessel <robertwessel2@yahoo.com> - 2014-10-09 13:44 -0500
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-10-09 22:31 +0200
Re: Intel Atom: pros/cons/hazzards? "Michael A. Terrell" <mike.terrell@earthlink.net> - 2014-10-09 17:29 -0400
Re: Intel Atom: pros/cons/hazzards? "Michael A. Terrell" <mike.terrell@earthlink.net> - 2014-10-09 17:31 -0400
Re: Intel Atom: pros/cons/hazzards? Robert Wessel <robertwessel2@yahoo.com> - 2014-10-09 21:25 -0500
Re: Intel Atom: pros/cons/hazzards? "Michael A. Terrell" <mike.terrell@earthlink.net> - 2014-10-09 23:27 -0400
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-10-09 21:56 -0700
Re: Intel Atom: pros/cons/hazzards? Stefan Reuther <stefan.news@arcor.de> - 2014-10-10 18:48 +0200
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-10-10 10:43 -0700
Re: Intel Atom: pros/cons/hazzards? mjb@signal11.invalid (Mike) - 2014-10-11 21:25 +0100
Re: Intel Atom: pros/cons/hazzards? krw@attt.bizz - 2014-10-10 18:27 -0400
Re: Intel Atom: pros/cons/hazzards? Jasen Betts <jasen@xnet.co.nz> - 2014-10-11 03:05 +0000
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-22 18:43 -0400
Re: Intel Atom: pros/cons/hazzards? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-09-22 23:36 +0000
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 16:48 -0700
Re: Intel Atom: pros/cons/hazzards? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-09-23 01:05 +0000
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 18:47 -0700
Re: Intel Atom: pros/cons/hazzards? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-09-23 02:11 +0000
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 22:24 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-23 00:29 -0400
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-23 10:07 +0200
Re: Intel Atom: pros/cons/hazzards? Les Cargill <lcargill99@comcast.com> - 2014-09-23 07:14 -0500
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-22 23:43 -0400
Re: Intel Atom: pros/cons/hazzards? krw@attt.bizz - 2014-09-23 13:14 -0400
Re: Intel Atom: pros/cons/hazzards? Robert Wessel <robertwessel2@yahoo.com> - 2014-09-23 18:18 -0500
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-23 19:28 -0400
Re: Intel Atom: pros/cons/hazzards? krw@attt.bizz - 2014-09-23 19:58 -0400
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-23 16:52 -0700
Re: Intel Atom: pros/cons/hazzards? krw@attt.bizz - 2014-09-23 19:57 -0400
Re: Intel Atom: pros/cons/hazzards? "Michael A. Terrell" <mike.terrell@earthlink.net> - 2014-10-08 12:39 -0400
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-22 18:38 -0400
Re: Intel Atom: pros/cons/hazzards? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-09-22 23:41 +0000
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-22 23:27 -0400
Re: Intel Atom: pros/cons/hazzards? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-09-23 05:34 +0000
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-23 02:21 -0400
Re: Intel Atom: pros/cons/hazzards? Robert Wessel <robertwessel2@yahoo.com> - 2014-09-24 09:42 -0500
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-23 09:51 -0700
Re: Intel Atom: pros/cons/hazzards? Robert Wessel <robertwessel2@yahoo.com> - 2014-09-23 18:23 -0500
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-23 16:53 -0700
Re: Intel Atom: pros/cons/hazzards? Robert Wessel <robertwessel2@yahoo.com> - 2014-09-24 08:15 -0500
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-24 10:52 -0700
Re: Intel Atom: pros/cons/hazzards? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-09-24 21:51 +0000
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-24 15:57 -0700
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-23 09:52 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-23 18:19 -0400
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-23 15:33 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-23 18:38 -0400
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-23 15:59 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-23 19:03 -0400
Re: Intel Atom: pros/cons/hazzards? Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-09-24 00:15 +0100
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-23 19:30 -0400
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-23 16:56 -0700
Re: Intel Atom: pros/cons/hazzards? David Brown <david.brown@hesbynett.no> - 2014-09-24 02:09 +0200
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-23 20:17 -0400
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-23 17:26 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-23 21:20 -0400
Re: Intel Atom: pros/cons/hazzards? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-09-23 23:42 +0000
Re: Intel Atom: pros/cons/hazzards? "Michael A. Terrell" <mike.terrell@earthlink.net> - 2014-10-08 12:41 -0400
Re: Intel Atom: pros/cons/hazzards? Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-09-22 17:03 +0100
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-22 10:19 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-22 15:21 -0400
Re: Intel Atom: pros/cons/hazzards? Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-09-22 12:55 +0100
Re: Intel Atom: pros/cons/hazzards? Jasen Betts <jasen@xnet.co.nz> - 2014-09-22 12:25 +0000
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 05:37 -0700
Re: Intel Atom: pros/cons/hazzards? Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-09-22 14:37 +0100
Re: Intel Atom: pros/cons/hazzards? Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-09-22 14:32 +0100
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 07:01 -0700
Re: Intel Atom: pros/cons/hazzards? Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-09-22 15:22 +0100
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 08:01 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-23 00:35 -0400
Re: Intel Atom: pros/cons/hazzards? Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2014-09-23 09:09 +0200
Re: Intel Atom: pros/cons/hazzards? Les Cargill <lcargill99@comcast.com> - 2014-09-23 07:16 -0500
Re: Intel Atom: pros/cons/hazzards? Andrew Smallshaw <andrews@sdf.lonestar.org> - 2014-09-23 14:45 +0000
Re: Intel Atom: pros/cons/hazzards? Robert Wessel <robertwessel2@yahoo.com> - 2014-09-23 10:08 -0500
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-23 10:03 -0700
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-23 13:52 -0700
Re: Intel Atom: pros/cons/hazzards? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-09-22 20:53 +0000
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 15:00 -0700
Re: Intel Atom: pros/cons/hazzards? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-09-22 22:14 +0000
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 15:51 -0700
Re: Intel Atom: pros/cons/hazzards? Robert Wessel <robertwessel2@yahoo.com> - 2014-09-23 10:17 -0500
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-23 13:57 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-23 18:28 -0400
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-22 04:39 -0700
Re: Intel Atom: pros/cons/hazzards? langwadt@fonz.dk - 2014-09-20 16:33 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-20 22:17 -0400
Re: Intel Atom: pros/cons/hazzards? langwadt@fonz.dk - 2014-09-21 12:24 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-22 00:00 -0400
Re: Intel Atom: pros/cons/hazzards? Jasen Betts <jasen@xnet.co.nz> - 2014-09-19 23:15 +0000
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-19 07:58 -0700
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-19 10:41 -0700
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-19 07:59 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-19 03:08 -0400
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-19 01:17 -0700
Re: Intel Atom: pros/cons/hazzards? josephkk <joseph_barrett@sbcglobal.net> - 2014-09-19 21:15 -0700
Re: Intel Atom: pros/cons/hazzards? Les Cargill <lcargill99@comcast.com> - 2014-09-20 14:36 -0500
Re: Intel Atom: pros/cons/hazzards? "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2014-09-19 10:02 +0200
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-19 04:20 -0400
Re: Intel Atom: pros/cons/hazzards? "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2014-09-18 16:20 +0200
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-18 10:25 -0700
Re: Intel Atom: pros/cons/hazzards? "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2014-09-19 09:36 +0200
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-19 01:27 -0700
Re: Intel Atom: pros/cons/hazzards? josephkk <joseph_barrett@sbcglobal.net> - 2014-09-19 21:35 -0700
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-20 11:54 -0700
Re: Intel Atom: pros/cons/hazzards? mroberds@att.net - 2014-09-18 19:33 +0000
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-18 13:18 -0700
Re: Intel Atom: pros/cons/hazzards? Przemek Klosowski <przemek@tux.dot.org> - 2014-09-21 12:34 +0000
Re: Intel Atom: pros/cons/hazzards? krw@attt.bizz - 2014-09-21 11:54 -0400
Re: Intel Atom: pros/cons/hazzards? edward.ming.lee@gmail.com - 2014-09-17 08:10 -0700
Re: Intel Atom: pros/cons/hazzards? Grant Edwards <invalid@invalid.invalid> - 2014-09-17 15:11 +0000
Re: Intel Atom: pros/cons/hazzards? Les Cargill <lcargill99@comcast.com> - 2014-09-17 22:53 -0500
Re: Intel Atom: pros/cons/hazzards? DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> - 2014-09-17 13:33 -0700
Re: Intel Atom: pros/cons/hazzards? Robert Wessel <robertwessel2@yahoo.com> - 2014-09-18 03:35 -0500
Re: Intel Atom: pros/cons/hazzards? Allan Herriman <allanherriman@hotmail.com> - 2014-09-18 13:16 +0000
Re: Intel Atom: pros/cons/hazzards? Anssi Saari <as@sci.fi> - 2014-09-25 13:51 +0300
Re: Intel Atom: pros/cons/hazzards? dplatt@coop.radagast.org (David Platt) - 2014-09-25 09:58 -0700
Re: Intel Atom: pros/cons/hazzards? Anssi Saari <as@sci.fi> - 2014-09-29 21:46 +0300
Re: Intel Atom: pros/cons/hazzards? Don Y <this@is.not.me.com> - 2014-09-25 10:07 -0700
Re: Intel Atom: pros/cons/hazzards? rickman <gnuarm@gmail.com> - 2014-09-25 18:32 -0400
Re: Intel Atom: pros/cons/hazzards? "Daniel Mandic" <daniel_mandic@hotmail.com> - 2014-10-10 09:53 +0000
Page 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2014-09-19 10:41 -0700 |
| Message-ID | <lvhq12$sav$1@speranza.aioe.org> |
| In reply to | #18105 |
On 9/19/2014 7:58 AM, DecadentLinuxUserNumeroUno wrote: > On Fri, 19 Sep 2014 11:53:40 +0200, David Brown > <david.brown@hesbynett.no> Gave us: > >> A kernel has to be built - but it certainly doesn't have to be built by >> the user. > > Something in your logic is missing or askew. I think his point is that most users can tolerate a "generic" kernel -- one that has every possibility accounted for. In a desktop environment, that may well be the case. OTOH, if you're designing a cost-sensitive "appliance", you probably DON'T want to accommodate every possibility -- because your hardware simply can't take advantage of them! In that case, why include support for something -- even "loadable modules" -- if it will never be used? In high reliability software, there is a concept called "dead code"; code that is never executed. It's presence in a product is seen as a flaw. It represents added complexity that is not used. And, added potential for flaws. E.g., *something* in the live CD kernel that I recently booted (elsewhere this thread) is causing the system to crash before it can even go single-user. Likewise, a Linux kernel on another live CD also caused the video to go wacky. Whatever that is, it represents a liability of those particular kernels. OTOH, when the live CD was built, I'm sure they reasoned that they wanted to include support for everything imaginable *on* that CD (even if some of that stuff tickles hardware that has not yet been imagined -- or, perhaps completely validated). That's the consequence of using a kernel that was NOT built by THIS user (for this hardware). Note that this is far less of a problem now (esp in the desktop machine world) than it was years ago. Because modern busses make it much easier to identify/probe particular hardware. OTOH, rolling your own hardware doesn't afford you this same level of protection. E.g., you can locate a particular peripheral wherever *you* deem fit in the address space; you can scramble the address or data lines to that peripheral; you can locate *other* peripherals in places where the probe for some other device can cause that other peripheral to lock up; etc. Hence the apparent value of building my own live CD with a set of progressively more capable kernels. So, booting the default kernel doesn't even try to go looking for devices and capabilities that aren't needed TO EXAMINE THE MACHINE'S HARDWARE (dmesg output). Just make sure the interface to the CD, text display and keyboard are operational. (alternatively, USB *instead* of -- not in ADDITION to -- the CD. "Minimalism") I suspect that is the approach folks like MS take. They settle on some basic set of capabilities that they REQUIRE from the hardware in the early stages of installation. So, they can at least communicate with the user to explain problems, etc.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> |
|---|---|
| Date | 2014-09-19 07:59 -0700 |
| Message-ID | <h5ho1ato90lsqb7ccfkn2n1r3pircihggl@4ax.com> |
| In reply to | #18100 |
On Fri, 19 Sep 2014 11:53:40 +0200, David Brown <david.brown@hesbynett.no> Gave us: > I don't know much about building kernels in the BSD world, >but in the Linux world it is a very long time since it was common to >bother building your own kernel. Out of touch much?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-19 03:08 -0400 |
| Message-ID | <lvgkq6$ths$1@dont-email.me> |
| In reply to | #18089 |
On 9/18/2014 8:18 PM, Don Y wrote: > On 9/18/2014 4:22 PM, rickman wrote: >> On 9/18/2014 6:53 PM, Don Y wrote: >>> On 9/18/2014 3:12 PM, rickman wrote: >>>>>>> I don't *think* these have integrated video. I tried booting >>>>>>> a NetBSD system and the video quickly scrambled (hard to see >>>>>>> the dmesg output to determine which device was probed at the >>>>>>> time). I'll have to make some time to investigate... >>>>>> >>>>>> Can't you boot it with the console being another machine over the >>>>>> network? >>>>> >>>>> Even assuming the NIC is recognized and autoconfigured, it doesn't >>>>> *appear* that the system is surviving this "scrambled video" >>>>> event. >>>>> >>>>> E.g., dmesg appears in red for this kernel. When the screen goes >>>>> wonky, I can see the red text that has been scrolling by (correctly) >>>>> up to this point -- amid a scrambled bunch of "white" video >>>>> (as if HLock was lost). The red text stops scrolling -- as if the >>>>> next probed item never got added to the output. >>>> >>>> That says to me the problem might well not be the video, but that the >>>> video is an unintended victim of the real problem. I believe this text >>>> stream can be redirected to a file, no? Maybe that is the way to >>>> go. Do >>>> a postmortem on the text file. >>> >>> Yes, but the text file has to be *stored* somewhere that isn't >>> volatile! I.e., you need writable media in the machine! ;) >> >> If you don't have writable media, what are you booting from, a CD with >> no HD? So put a HD on it... > > Correct. It takes a 2.5" SATA drive. All of the 2.5" SATA drives > that I have a large and "have stuff on them". So, putting a disk > drive in the box means cleaning off one of these -- just to see > why the video is getting scrambled, etc. > > As it isn't a "pressing need" (i.e., it can surely wait a week > or two), the cost of making a disk *available* for it far exceeds > the value of doing so! :-/ > > I *think* I have some "converters" that could let me adapt one > of my PATA drives. OTOH, they might be the exact "wrong" > type of converters... > > (I could also drag out a 3" SATA drive, am external power supply > and hack together some suitable cables... again, a lot of work > vs. just waiting until I can get my hands on some smaller/disposable > SATA drives) If you have some larger drives available, can't you just copy one of the laptop drives to the larger one, then it is free for the Atom system... That would be 5 minutes of your time and whatever time for it to copy. Or can the Linux distro boot from a USB stick? Surely you have one of those around... Aren't there a bunch of ways to skin this cat? >>> I.e., the only way I can move forward is to build a "system" >>> and then let that system boot -- having a disk on which to >>> scribble log messages. Of course, if the system doesn't >>> get to multiuser state (or, if the network IF doesn't come up), >>> then there is no way to troubleshoot *that*. >> >> So adding a HD is "building a system"? The software you are booting >> doesn't know about hard drives? Really? > > No. Add a hard drive and install the system *on* that hard drive > (so that the system knows it has a place to scribble -- which it > doesn't know when booting off a read-only medium). > > If you're going to put the system on the disk, then you might > as well spend the half hour to customize the kernel so it stands > a better chance of getting past whatever is causing the live CD to > scramble video... I thought the whole point was you didn't know what to configure the system for! >>> So, best shot for getting The Answers on the first shot is to >>> build a stripped down kernel -- remove any drivers that are >>> not essential. *Hope* it gets through the boot sequence >>> (to "single-user"). Then, examine the dmesg output to see >>> which devices it detected but didn't "configure" (because the >>> corresponding drivers weren't wired in). >> >> If you want to do all that work. Or you could plug a hard drive to it. > > See above. Just *adding* a hard disk to the system (AND CONTINUING > TO BOOT OFF THE LIVE CD) will result in exactly the same situation > that I have now -- messages won't get stored anywhere because the > system has no knowledge of how "acceptable" it would be to > scribble on that disk! > > Normally, the kernel buffers diagnostic/log messages while it is > booting. When it is "up" (or, nearly so), these are flushed to > log files -- typically under /var/log. If the entire file system > is represented by a live CD, then /var/log is not writeable. > No way to see what it *would* have scribbled there! If you are booting from a CD I guess there is no way to tell the system that it needs to log to the HD anyway. > [Of course, if the kernel never makes it all the way "up", then > all bets are off, anyway!] > > If the kernel manages to boot, you can still examine these "in core" > messages AS IF they were entered in the log file (dmesg(8) dumps > the "system message buffer"). So, in *most* situations, I can > boot a live CD, wait for the prompt, type "dmesg | more" and examine > the various messages to see what devices are present, how much > memory, etc. > > If I can get to a command prompt, I can manually mount a thumb > drive and copy the messages to that medium (dmesg > /mnt/messages.txt) > > Or, I can manually bring up a network interface and move stuff > on/off via that mechanism. > > [But, I need access to a command prompt to do so!] > >>> If you can get a console, building a "custom" NetBSD kernel >>> tailored for that particular device is no more than half an hour, >>> start to finish. >> >> Plugging in a hard drive is 5 minutes and the first 4 is finding a cable. > > See above. All that would do is *eventually* list a hard disk > as one of the devices probed in the system -- *if* the boot > managed to make it that far. > > Take a virgin machine. Try to install Linux, Windows, BeOS, OSX, etc. > You've got executables on a CD/DVD. And, a disk onto which you can > scribble! > > But, if you can't get to a command prompt, you can't tell the > machine to *use* that disk to scribble! Well duh! Is it that hard to make an installation on the HD without recompiling it all? I can do that with Windows. You just use a different machine. >>>>>>> Yes, that's what I've already been doing on the various boxes. >>>>>>> Lets me build custom kernels for each box's capabilities, etc. >>>>>>> >>>>>>> Perhaps next step will be to try a *Windows* install if only to >>>>>>> get an enumeration of the various "devices" in the box! Then, >>>>>>> use that information to build an appropriate kernel. >>>>>> >>>>>> Linux can't do that? >>>>> >>>>> It, perhaps, can. I just don't run Linux. And, imagine it >>>>> wasn't *designed* with Linux in mind but, rather, "Windows" >>>>> (of some flavor). So, I'd expect putting Windows on it would >>>>> "work" -- at least enough to allow me to inspect its hardware >>>>> complement. >>>>> >>>>> I'll have to see if I have a smallish 2.5" SATA drive that I >>>>> can "waste". All I've found so far are > 500GB. >>>> >>>> Is NetBSD that different from Linux? I figured it was just another >>>> flavor. >>> >>> Yes. Linux is JUST a kernel. NetBSD, FreeBSD, OpenBSD, PicoBSD, >>> yadayadaBSD, etc. are all OS environments. E.g., what you would >>> call "distros" in the Linux camp. >> >> When I say Linux, I am referring to all of those collectively. When you >> say you don't run Linux, you mean... whatever... this can be >> exasperating sometimes. > > That's like saying "Windows" and meaning OSX, Linux, *BSD, Solaris, > etc. Sometimes you make no sense. You just said Linux is the kernal for all of those systems. Now you are saying it is the kernal for Windows too... ok Is BSD not at all based on Linux? Regardless, don't get hung up on the terminology. > *BSD is different from Linux as Linux is different from Windows and > Windows is different from OSX... > > "I don't run Linux" I also don't run OSX. So, if OSX could "do it", > I'd be just as SOL. > >> The point is that why can't your version of Linux "distro" do the >> enumeration? > > My NetBSD "live cd" never gets to a command prompt for me to be > able to *see* what it is saying! I can watch the first part > of the boot process... see the first group of devices successfully > probed (have to look fast because it scrolls by in a jiffy)... > But, it gets to a point where the screen gets scrambled. > > Looking at the screen, I can see much of the previous messages > (in red-colored text) still present. But, it is as if the > HSync has been lost so nothing is clear/readable. > > What I want/need to know is the message that it was getting ready to > emit just as the screen went wonky. If the kernel is truly crashed, > then I wouldn't be able to get this message from it even if I had > a means of typing: > dmesg | more > If just the video is crashed, it is possible that the kernel is > still functioning (doubtful) but I can't talk to it -- because > I can't type at the "console" and the network isn't "up". > > The solution is to install a simpler kernel (e.g., I can live > without USB support, network interface, wireless, etc. WHILE > I am troubleshooting) and then watch to see what the LIKELY > problem may be. > > The fact that the kernel is able to emit messages for a portion > of the boot process suggests the video can operate as a "dumb > text console" (because it *is* -- up until that point!). I > just need to make sure nothing interferes with it *continuing* > to do so. > > With a system on disk (or, CD if I want to endlessly burn CD's!), > I can boot a specific kernel: > boot netbsd.STRIPPED_DOWN > and observe the results. Then, modify this kernel (add in some > devices not present in STRIPPED_DOWN) and reboot, specifying this > *new* kernel: > boot netbsd.A_FEW_DEVICES > and repeat until I find the change that causes the screen to go > wonky. Or others have suggested you work over a serial port. Is there no serial port on this machine? Can you use a USB serial port? >>>> I don't think the computers are designed for any OS. The OS is >>>> modified >>>> for the newest processors and chips. Motherboards are just designed >>>> for >>>> target markets. >>> >>> Yes, but if a market embraces Windows, then the product effectively >>> was "designed for Windows". >> >> Ok, whatever.... by your definition of "designed for Windows" it has no >> useful meaning. > > It means I am more likely to find a Windows release that will > run "flawlessly" on this particular set of hardware. Even if > the device/driver that is (probably) causing my problem is > completely proprietary/closed. > > OTOH, expecting Linux, *BSD, OSX to run on "any random hardware" > is a bit of a crap shoot. I think it means Windows is designed to run on more hardware than the various alternative OSs. The hardware is simply designed to run... -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2014-09-19 01:17 -0700 |
| Message-ID | <lvgp10$4s7$1@speranza.aioe.org> |
| In reply to | #18092 |
On 9/19/2014 12:08 AM, rickman wrote:
>>>>>> E.g., dmesg appears in red for this kernel. When the screen goes
>>>>>> wonky, I can see the red text that has been scrolling by (correctly)
>>>>>> up to this point -- amid a scrambled bunch of "white" video
>>>>>> (as if HLock was lost). The red text stops scrolling -- as if the
>>>>>> next probed item never got added to the output.
>>>>>
>>>>> That says to me the problem might well not be the video, but that the
>>>>> video is an unintended victim of the real problem. I believe this
>>>>> text
>>>>> stream can be redirected to a file, no? Maybe that is the way to
>>>>> go. Do
>>>>> a postmortem on the text file.
>>>>
>>>> Yes, but the text file has to be *stored* somewhere that isn't
>>>> volatile! I.e., you need writable media in the machine! ;)
>>>
>>> If you don't have writable media, what are you booting from, a CD with
>>> no HD? So put a HD on it...
>>
>> Correct. It takes a 2.5" SATA drive. All of the 2.5" SATA drives
>> that I have a large and "have stuff on them". So, putting a disk
>> drive in the box means cleaning off one of these -- just to see
>> why the video is getting scrambled, etc.
>>
>> As it isn't a "pressing need" (i.e., it can surely wait a week
>> or two), the cost of making a disk *available* for it far exceeds
>> the value of doing so! :-/
>>
>> I *think* I have some "converters" that could let me adapt one
>> of my PATA drives. OTOH, they might be the exact "wrong"
>> type of converters...
>>
>> (I could also drag out a 3" SATA drive, am external power supply
>> and hack together some suitable cables... again, a lot of work
>> vs. just waiting until I can get my hands on some smaller/disposable
>> SATA drives)
>
> If you have some larger drives available, can't you just copy one of the
> laptop drives to the larger one, then it is free for the Atom system...
> That would be 5 minutes of your time and whatever time for it to copy.
The 500G drives are 2.5's. So, to clear one off, I would need
at least 500G of space on another (e.g., 3.5") drive.
> Or can the Linux distro boot from a USB stick? Surely you have one of
> those around...
>
> Aren't there a bunch of ways to skin this cat?
Sure! All take varying amounts of time. And, EVENTUALLY, I will
*still* have to build a kernel to run on this machine! So, why
not just wait until I have a smaller (capacity) drive that can
STAY in the machine, forever? Build the kernel appropriately
and solve ALL the problems (instead of investing time just
to figure out what NOT to put in the kernel -- that I will still
have to build and configure even after I know what this machine's
"issue" happens to be!)
>>>> I.e., the only way I can move forward is to build a "system"
>>>> and then let that system boot -- having a disk on which to
>>>> scribble log messages. Of course, if the system doesn't
>>>> get to multiuser state (or, if the network IF doesn't come up),
>>>> then there is no way to troubleshoot *that*.
>>>
>>> So adding a HD is "building a system"? The software you are booting
>>> doesn't know about hard drives? Really?
>>
>> No. Add a hard drive and install the system *on* that hard drive
>> (so that the system knows it has a place to scribble -- which it
>> doesn't know when booting off a read-only medium).
>>
>> If you're going to put the system on the disk, then you might
>> as well spend the half hour to customize the kernel so it stands
>> a better chance of getting past whatever is causing the live CD to
>> scramble video...
>
> I thought the whole point was you didn't know what to configure the
> system for!
You build a stripped down kernel. One that doesn't have various
video, network, wireless, SCSI HBA, etc. drivers present. I.e.,
so all it knows about is a "barebones PC architecture" (hence the
reason for my initial question re: Atom's).
If you can't boot *that*, then there's no hope! :>
Once you *can*, you examine the dmesg output from the first boot.
It will tell you which devices are present but not yet configured
(i.e., missing drivers) in the "stripped down kernel".
Add those lines back into the kernel's configuration file.
Rebuild. Install as final OPERATING kernel.
In practice, you start with a kernel configuration file
that supports everything and comment out all but the most basic
components -- to arrive at the "barebones PC". Call this
netbsd.BAREBONES (kernels are named /netbsd by convention).
Examine the dmesg from this boot. Find the drivers that
are missing (by notes in the dmesg) and uncomment them in your
"new" kernel configuration file. Then:
config NEWKERNELNAME
cd ../compile/NEWKERNELNAME
make depends
make
make install
and reboot. If you've been observant, you've now got a kernel
(NEWKERNELNAME) that supports everything you want in the new
hardware/machine.
As the Atom's will run x86 code, the initial BAREBONES kernel
can be built on any x86 NetBSD box and just copied onto the
disk that will LIVE in the new machine -- along with the rest
of the "system". Once it has booted, the new kernel can be
built ON that new machine.
A few weeks ago, I did exactly this for another "new" box:
made a copy of an existing x86 system (complete filesystem)
on a new disk drive. Installed drive. Noted which devices
were not correctly probed (dmesg). Modified the kernel
configuration file. Rebuild (as illustrated above). Then,
reboot.
[Unfortunately, the laptop drive that I did this on has already
died. Unsure if it was from abuse or if it was just "getting on
in years". So, I'll have to do it again -- perhaps using one of
these boxes to replace that machine]
>>>> So, best shot for getting The Answers on the first shot is to
>>>> build a stripped down kernel -- remove any drivers that are
>>>> not essential. *Hope* it gets through the boot sequence
>>>> (to "single-user"). Then, examine the dmesg output to see
>>>> which devices it detected but didn't "configure" (because the
>>>> corresponding drivers weren't wired in).
>>>
>>> If you want to do all that work. Or you could plug a hard drive to it.
>>
>> See above. Just *adding* a hard disk to the system (AND CONTINUING
>> TO BOOT OFF THE LIVE CD) will result in exactly the same situation
>> that I have now -- messages won't get stored anywhere because the
>> system has no knowledge of how "acceptable" it would be to
>> scribble on that disk!
>>
>> Normally, the kernel buffers diagnostic/log messages while it is
>> booting. When it is "up" (or, nearly so), these are flushed to
>> log files -- typically under /var/log. If the entire file system
>> is represented by a live CD, then /var/log is not writeable.
>> No way to see what it *would* have scribbled there!
>
> If you are booting from a CD I guess there is no way to tell the system
> that it needs to log to the HD anyway.
Correct. If, OTOH, the system was booting from a hard disk,
then /var/log would be writeable and the log files would populate
that portion of the filesystem in the natural course of events.
Similarly, if I can get to a command prompt, I can manually mount
some other writeable medium (e.g., thumb drive).
>>>> If you can get a console, building a "custom" NetBSD kernel
>>>> tailored for that particular device is no more than half an hour,
>>>> start to finish.
>>>
>>> Plugging in a hard drive is 5 minutes and the first 4 is finding a
>>> cable.
>>
>> See above. All that would do is *eventually* list a hard disk
>> as one of the devices probed in the system -- *if* the boot
>> managed to make it that far.
>>
>> Take a virgin machine. Try to install Linux, Windows, BeOS, OSX, etc.
>> You've got executables on a CD/DVD. And, a disk onto which you can
>> scribble!
>>
>> But, if you can't get to a command prompt, you can't tell the
>> machine to *use* that disk to scribble!
>
> Well duh! Is it that hard to make an installation on the HD without
> recompiling it all? I can do that with Windows. You just use a
> different machine.
Yes, *knowing* (point of my post!) that Atom's can execute i386 binaries
in a functionally equivalent manner means I can just build a BAREBONES
kernel on another machine and copy the "complete filesystem" onto
the new disk. Then, install in the new machine.
>>>>>>>> Yes, that's what I've already been doing on the various boxes.
>>>>>>>> Lets me build custom kernels for each box's capabilities, etc.
>>>>>>>>
>>>>>>>> Perhaps next step will be to try a *Windows* install if only to
>>>>>>>> get an enumeration of the various "devices" in the box! Then,
>>>>>>>> use that information to build an appropriate kernel.
>>>>>>>
>>>>>>> Linux can't do that?
>>>>>>
>>>>>> It, perhaps, can. I just don't run Linux. And, imagine it
>>>>>> wasn't *designed* with Linux in mind but, rather, "Windows"
>>>>>> (of some flavor). So, I'd expect putting Windows on it would
>>>>>> "work" -- at least enough to allow me to inspect its hardware
>>>>>> complement.
>>>>>>
>>>>>> I'll have to see if I have a smallish 2.5" SATA drive that I
>>>>>> can "waste". All I've found so far are > 500GB.
>>>>>
>>>>> Is NetBSD that different from Linux? I figured it was just another
>>>>> flavor.
>>>>
>>>> Yes. Linux is JUST a kernel. NetBSD, FreeBSD, OpenBSD, PicoBSD,
>>>> yadayadaBSD, etc. are all OS environments. E.g., what you would
>>>> call "distros" in the Linux camp.
>>>
>>> When I say Linux, I am referring to all of those collectively. When you
>>> say you don't run Linux, you mean... whatever... this can be
>>> exasperating sometimes.
>>
>> That's like saying "Windows" and meaning OSX, Linux, *BSD, Solaris,
>> etc.
>
> Sometimes you make no sense. You just said Linux is the kernal for all
> of those systems. Now you are saying it is the kernal for Windows
> too... ok
No! Linux is *a* kernel. In DOS parlance, it is COMMAND.COM...
for Linux Distros -- and ONLY for Linux Distros!
NetBSD's kernel (entirely different source code -- because there's
no GPL code contained within!) is used in NetBSD. FreeBSD's
kernel is used in FreeBSD. OpenBSD's kernel is used in OpenBSD.
etc. The *BSD kernels share some code but are maintained by
different groups and with different goals. So, a FreeBSD kernel
won't support NetBSD executables and vice versa (actually, there
are some compatibility options that can be used but the kernels
aren't just "drop in replacements").
My above statement was meant to illustrate that calling all of
these (NetBSD, OpenBSD, FreeBSD, OSX, PicoBSD, etc.) "Linux" is
wrong. Just like it would be wrong to call Linux "Windows"!
NetBSD is NetBSD. Linux is Linux. What they have in common is
they are maintained in an "open" fashion -- unlike "Windows".
Linux, e.g., had its roots in more of a SysV flavor while
the BSD's were (not surprisingly) derived from the Berkeley
Software Distribution (of "UNIX").
> Is BSD not at all based on Linux?
No. Different evolutions, goals, licenses, etc. That was the
point I was trying to make.
> Regardless, don't get hung up on the terminology.
>> With a system on disk (or, CD if I want to endlessly burn CD's!),
>> I can boot a specific kernel:
>> boot netbsd.STRIPPED_DOWN
>> and observe the results. Then, modify this kernel (add in some
>> devices not present in STRIPPED_DOWN) and reboot, specifying this
>> *new* kernel:
>> boot netbsd.A_FEW_DEVICES
>> and repeat until I find the change that causes the screen to go
>> wonky.
>
> Or others have suggested you work over a serial port. Is there no
> serial port on this machine? Can you use a USB serial port?
If the kernel is crashing, then it doesn't matter if I use a
serial port or the console. Once <whatever> device is probed
during the boot, the system will "go away". A dead serial console
is just as bad as a dead *console*!
Instead of trying to avoid the problem, I'll just *solve* it;
when I have a smaller disk that I am willing to *commit* to this
machine!
Solve problem and end up with *working* machine -- instead of
just a description of the problem followed by actually having to
MAKE that working machine!
As I said, this is usually a pretty simple process. This is the first
time that I've not been able to take "any old kernel" and get
to a point where I can start modifying that kernel. Usually,
the big issues are NICs (so, no network connectivity until you
get the "right" kernel built) and more exotic I/O's (e.g., SCSI
HBA's, wireless adapters, PCMCIA support, etc.).
This is the first time that the video hardware has not liked
being tickled the way the kernel wants to tickle it!
[toc] | [prev] | [next] | [standalone]
| From | josephkk <joseph_barrett@sbcglobal.net> |
|---|---|
| Date | 2014-09-19 21:15 -0700 |
| Message-ID | <djvp1apj41t8ojpeg4niuaojk47fo8jnvn@4ax.com> |
| In reply to | #18096 |
On Fri, 19 Sep 2014 01:17:51 -0700, Don Y <this@is.not.me.com> wrote: > >>>> When I say Linux, I am referring to all of those collectively. When you >>>> say you don't run Linux, you mean... whatever... this can be >>>> exasperating sometimes. >>> >>> That's like saying "Windows" and meaning OSX, Linux, *BSD, Solaris, >>> etc. >> >> Sometimes you make no sense. You just said Linux is the kernal for all >> of those systems. Now you are saying it is the kernal for Windows >> too... ok > >No! Linux is *a* kernel. In DOS parlance, it is COMMAND.COM... >for Linux Distros -- and ONLY for Linux Distros! Umm, No. DOS command.com is like one of the shell languages sh, csh, ash, bash, etc., The underlying system is in things like io.sys and dos.sys. ?-)
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2014-09-20 14:36 -0500 |
| Subject | Re: Intel Atom: pros/cons/hazzards? |
| Message-ID | <lvkl1j$l7l$2@dont-email.me> |
| In reply to | #18124 |
josephkk wrote: > On Fri, 19 Sep 2014 01:17:51 -0700, Don Y <this@is.not.me.com> wrote: > >> >>>>> When I say Linux, I am referring to all of those collectively. When you >>>>> say you don't run Linux, you mean... whatever... this can be >>>>> exasperating sometimes. >>>> >>>> That's like saying "Windows" and meaning OSX, Linux, *BSD, Solaris, >>>> etc. >>> >>> Sometimes you make no sense. You just said Linux is the kernal for all >>> of those systems. Now you are saying it is the kernal for Windows >>> too... ok >> >> No! Linux is *a* kernel. In DOS parlance, it is COMMAND.COM... >> for Linux Distros -- and ONLY for Linux Distros! > > Umm, No. DOS command.com is like one of the shell languages sh, csh, ash, > bash, etc., > The underlying system is in things like io.sys and dos.sys. > > ?-) > > The underlying system is behind Int21h -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> |
|---|---|
| Date | 2014-09-19 10:02 +0200 |
| Message-ID | <op.xmfcm0c4j0diun@thanatos.indes.com> |
| In reply to | #18088 |
Op Fri, 19 Sep 2014 01:22:55 +0200 schreef rickman <gnuarm@gmail.com>: > On 9/18/2014 6:53 PM, Don Y wrote: >> On 9/18/2014 3:12 PM, rickman wrote: >>> Is NetBSD that different from Linux? I figured it was just another >>> flavor. >> >> Yes. Linux is JUST a kernel. NetBSD, FreeBSD, OpenBSD, PicoBSD, >> yadayadaBSD, etc. are all OS environments. E.g., what you would >> call "distros" in the Linux camp. > > When I say Linux, I am referring to all of those collectively. Please don't. http://www.freebsdnews.net/wp-content/uploads/unix_family_history_tree_1600x1200.jpg It's like saying birds to refer to all dinosaurs. It doesn't make any sense from a phylogenic standpoint. -- (Remove the obvious prefix to reply privately.) Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-19 04:20 -0400 |
| Message-ID | <lvgp16$npm$1@dont-email.me> |
| In reply to | #18095 |
On 9/19/2014 4:02 AM, Boudewijn Dijkstra wrote: > Op Fri, 19 Sep 2014 01:22:55 +0200 schreef rickman <gnuarm@gmail.com>: >> On 9/18/2014 6:53 PM, Don Y wrote: >>> On 9/18/2014 3:12 PM, rickman wrote: >>>> Is NetBSD that different from Linux? I figured it was just another >>>> flavor. >>> >>> Yes. Linux is JUST a kernel. NetBSD, FreeBSD, OpenBSD, PicoBSD, >>> yadayadaBSD, etc. are all OS environments. E.g., what you would >>> call "distros" in the Linux camp. >> >> When I say Linux, I am referring to all of those collectively. > > Please don't. > http://www.freebsdnews.net/wp-content/uploads/unix_family_history_tree_1600x1200.jpg > > > It's like saying birds to refer to all dinosaurs. It doesn't make any > sense from a phylogenic standpoint. "Ontogeny recapitulates phylogeny" - Ernst Haeckel -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> |
|---|---|
| Date | 2014-09-18 16:20 +0200 |
| Message-ID | <op.xmdzgkoij0diun@thanatos.indes.com> |
| In reply to | #18074 |
Op Thu, 18 Sep 2014 09:28:45 +0200 schreef Don Y <this@is.not.me.com>: > On 9/17/2014 2:44 PM, mroberds@att.net wrote: >> In sci.electronics.design Don Y <this@is.not.me.com> wrote: > >>>> If you wanted to run the graphics at full capability, though, you >>>> sometimes needed a driver from Intel or the SBC manufacturer, and you >>>> would run into the usual problem, which is that their unspecified >>>> "Linux driver" depended on a particular kernel version down to the >>>> ninth decimal place. >>> >>> Exactly. So much for "open" software! :> >> >> If I remember right, the proprietary graphics driver was closed-source. >> It's entirely possible, and (I am not a lawyer and this is not legal >> advice) probably within the terms of the GNU GPL, and other open-source >> licenses, to have proprietary software running "on top of" an open- >> source OS. It just tends to be a pain in the butt in practice. > > I don't *think* these have integrated video. I tried booting > a NetBSD system and the video quickly scrambled (hard to see > the dmesg output to determine which device was probed at the > time). I'll have to make some time to investigate... *BSD supports serial console for headless boxen. If graphics probing causes problems, then you can disable the relevant drivers without rebuilding the kernel. -- (Remove the obvious prefix to reply privately.) Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2014-09-18 10:25 -0700 |
| Message-ID | <lvf4n6$ddb$1@speranza.aioe.org> |
| In reply to | #18082 |
On 9/18/2014 7:20 AM, Boudewijn Dijkstra wrote: > Op Thu, 18 Sep 2014 09:28:45 +0200 schreef Don Y <this@is.not.me.com>: >> On 9/17/2014 2:44 PM, mroberds@att.net wrote: >>> In sci.electronics.design Don Y <this@is.not.me.com> wrote: >> >>>>> If you wanted to run the graphics at full capability, though, you >>>>> sometimes needed a driver from Intel or the SBC manufacturer, and you >>>>> would run into the usual problem, which is that their unspecified >>>>> "Linux driver" depended on a particular kernel version down to the >>>>> ninth decimal place. >>>> >>>> Exactly. So much for "open" software! :> >>> >>> If I remember right, the proprietary graphics driver was closed-source. >>> It's entirely possible, and (I am not a lawyer and this is not legal >>> advice) probably within the terms of the GNU GPL, and other open-source >>> licenses, to have proprietary software running "on top of" an open- >>> source OS. It just tends to be a pain in the butt in practice. >> >> I don't *think* these have integrated video. I tried booting >> a NetBSD system and the video quickly scrambled (hard to see >> the dmesg output to determine which device was probed at the >> time). I'll have to make some time to investigate... > > *BSD supports serial console for headless boxen. If graphics probing > causes problems, then you can disable the relevant drivers without > rebuilding the kernel. Yes, the problem is figuring out *what* is causing the box to "hang". Note that it could be "something else" that just happens to tickle some graphics I/O, etc. Until I can *see* the dmesg output, it's just a guessing game. Easier to build a stripped down kernel with *nothing*, see what's going on, make note of the "not configured" devices, then add then back in. (sigh) Everything just takes *time* :-/
[toc] | [prev] | [next] | [standalone]
| From | "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> |
|---|---|
| Date | 2014-09-19 09:36 +0200 |
| Message-ID | <op.xmfbfahbj0diun@thanatos.indes.com> |
| In reply to | #18083 |
Op Thu, 18 Sep 2014 19:25:13 +0200 schreef Don Y <this@is.not.me.com>: > On 9/18/2014 7:20 AM, Boudewijn Dijkstra wrote: >> Op Thu, 18 Sep 2014 09:28:45 +0200 schreef Don Y <this@is.not.me.com>: >>> On 9/17/2014 2:44 PM, mroberds@att.net wrote: >>>> In sci.electronics.design Don Y <this@is.not.me.com> wrote: >>> >>> [...] I tried booting >>> a NetBSD system and the video quickly scrambled (hard to see >>> the dmesg output to determine which device was probed at the >>> time). I'll have to make some time to investigate... >> >> *BSD supports serial console for headless boxen. If graphics probing >> causes problems, then you can disable the relevant drivers without >> rebuilding the kernel. > > Yes, the problem is figuring out *what* is causing the box to "hang". > Note that it could be "something else" that just happens to tickle > some graphics I/O, etc. My point was that you should be able to see this when using a serial console. -- (Remove the obvious prefix to reply privately.) Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2014-09-19 01:27 -0700 |
| Message-ID | <lvgpjb$6a9$1@speranza.aioe.org> |
| In reply to | #18094 |
On 9/19/2014 12:36 AM, Boudewijn Dijkstra wrote: > Op Thu, 18 Sep 2014 19:25:13 +0200 schreef Don Y <this@is.not.me.com>: >> On 9/18/2014 7:20 AM, Boudewijn Dijkstra wrote: >>> Op Thu, 18 Sep 2014 09:28:45 +0200 schreef Don Y <this@is.not.me.com>: >>>> On 9/17/2014 2:44 PM, mroberds@att.net wrote: >>>>> In sci.electronics.design Don Y <this@is.not.me.com> wrote: >>>> >>>> [...] I tried booting >>>> a NetBSD system and the video quickly scrambled (hard to see >>>> the dmesg output to determine which device was probed at the >>>> time). I'll have to make some time to investigate... >>> >>> *BSD supports serial console for headless boxen. If graphics probing >>> causes problems, then you can disable the relevant drivers without >>> rebuilding the kernel. >> >> Yes, the problem is figuring out *what* is causing the box to "hang". >> Note that it could be "something else" that just happens to tickle >> some graphics I/O, etc. > > My point was that you should be able to see this when using a serial > console. No, it seems that the machine is locking up when this happens. In the past, I've always just built a GENERIC kernel, partitioned the new disk, newfs(1) all partitions, filled fstab(5) and copied all the file system from a "template" system onto the new disk... all from within that "template system". Then, unplug the disk and install it in the new machine. EXPECT the network not to work and other devices to need to be tweeked. But, copy the GENERIC kernel configuration to NEWMACHINE, drop into vi(1) and edit NEWMACHINE to add/remove/change the appropriate lines. Build new kernel (now I am *on* the new machine!) and install it. This is the first time that I have *had* to rely on a live CD. Lesson learned: build a live cd that has a barebones kernel (which tries to be the least of all worlds) instead of GENERIC (which tries to be all things to all machines). I.e., instead of trying to have a running system on a live CD, try for a DEBUGGABLE system.
[toc] | [prev] | [next] | [standalone]
| From | josephkk <joseph_barrett@sbcglobal.net> |
|---|---|
| Date | 2014-09-19 21:35 -0700 |
| Message-ID | <up0q1apmaivmdc514i2kpcprv3egrdl9nm@4ax.com> |
| In reply to | #18098 |
On Fri, 19 Sep 2014 01:27:38 -0700, Don Y <this@is.not.me.com> wrote: >On 9/19/2014 12:36 AM, Boudewijn Dijkstra wrote: >> Op Thu, 18 Sep 2014 19:25:13 +0200 schreef Don Y <this@is.not.me.com>: >>> On 9/18/2014 7:20 AM, Boudewijn Dijkstra wrote: >>>> Op Thu, 18 Sep 2014 09:28:45 +0200 schreef Don Y <this@is.not.me.com>: >>>>> On 9/17/2014 2:44 PM, mroberds@att.net wrote: >>>>>> In sci.electronics.design Don Y <this@is.not.me.com> wrote: >>>>> >>>>> [...] I tried booting >>>>> a NetBSD system and the video quickly scrambled (hard to see >>>>> the dmesg output to determine which device was probed at the >>>>> time). I'll have to make some time to investigate... >>>> >>>> *BSD supports serial console for headless boxen. If graphics probing >>>> causes problems, then you can disable the relevant drivers without >>>> rebuilding the kernel. >>> >>> Yes, the problem is figuring out *what* is causing the box to "hang". >>> Note that it could be "something else" that just happens to tickle >>> some graphics I/O, etc. >> >> My point was that you should be able to see this when using a serial >> console. > >No, it seems that the machine is locking up when this happens. > >In the past, I've always just built a GENERIC kernel, partitioned >the new disk, newfs(1) all partitions, filled fstab(5) and copied >all the file system from a "template" system onto the new disk... >all from within that "template system". > >Then, unplug the disk and install it in the new machine. EXPECT >the network not to work and other devices to need to be tweeked. >But, copy the GENERIC kernel configuration to NEWMACHINE, drop >into vi(1) and edit NEWMACHINE to add/remove/change the appropriate >lines. Build new kernel (now I am *on* the new machine!) and >install it. > >This is the first time that I have *had* to rely on a live CD. >Lesson learned: build a live cd that has a barebones kernel >(which tries to be the least of all worlds) instead of GENERIC >(which tries to be all things to all machines). I.e., instead >of trying to have a running system on a live CD, try for a >DEBUGGABLE system. Don, this whole fufarah has impressed with NetBSD and its adaptability. I must really give it another look soon. ?-)
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2014-09-20 11:54 -0700 |
| Message-ID | <lvkim2$3bv$1@speranza.aioe.org> |
| In reply to | #18125 |
Hi Joseph,
On 9/19/2014 9:35 PM, josephkk wrote:
> On Fri, 19 Sep 2014 01:27:38 -0700, Don Y <this@is.not.me.com> wrote:
>> This is the first time that I have *had* to rely on a live CD.
>> Lesson learned: build a live cd that has a barebones kernel
>> (which tries to be the least of all worlds) instead of GENERIC
>> (which tries to be all things to all machines). I.e., instead
>> of trying to have a running system on a live CD, try for a
>> DEBUGGABLE system.
>
> Don, this whole fufarah has impressed with NetBSD and its adaptability. I
> must really give it another look soon.
It depends a lot on what your goals are. I use NetBSD primarily to host
"services": my DNS, DHCP, TFTP, font, file, web, database, etc. servers
all run on NetBSD boxen. They typically see very long uptimes (weeks,
months, years). Performance is never an issue as I'm not a "commercial
site" with lots of traffic, etc. Services tend to run headless so I
am mainly concerned that the boxes boot reliably (so I don't have to drag
out a monitor and keyboard to talk to them!) and stay up "indefinitely"
(including recovering from power outages "unattended").
I like the fact that I can stuff a disk in a USB enclosure, plug that
into a running system, partition the disk (disklabel), create the file
systems (newfs), mount them somewhere convenient, copy the appropriate
portions of the "hosting" file system onto that mount point (tar), build
a kernel for that new system, unmount/unplug the USB drive and have a
drive that is "ready to boot" on some new machine -- all in a matter of
a few hours (most of that time spent deciding which files to copy and
waiting for them to be copied over the USB -- only a few of my machines
support hot-plugging drives).
Once the "new" system boots, I just have to tweek rc.conf(5) (fix hostname,
add an entry for it in hosts(5), adjust any services that I may want to
enable/disable, etc.) and verify all the desired devices are supported in
the kernel that I built (e.g., I probably will NOT want the wireless
device in the Atom's enabled *or* supported!)
[I assign static names/IPs to all of my hosts. I rely on the name server
box to *resolve* those names -- but not on the DHCP server to *assign* them!
That way, if the DHCP server is unavailable, I can still boot a "named" box
and talk to it. Like most folks, I choose names that are easy to memorize:
printers are Curly, Larry, Moe and Shemp with Curly at x.x.x.111; Sun boxen
are George, Jane, Judy and Elroy with George at x.x.x.71 (actually, I think
Elroy just got discarded); wireless AP's are Rosey, RUDI and Mack; PC's are
Pinky, TheBrain, Tennessee, Chumley, etc. "Mnemonic aids" so I can deduce
what the name server would likely report when queried for a particular name!]
I do very little "interactively" under NetBSD: primarily write and
debug code. My "desktop" is incredibly unadorned: no fancy wallpaper,
no animated icons, etc. Heck, I don't even have a *clock* displayed!
I'm more than happy with a root-weave backdrop -- most of it will be
obscured by xterm/xemacs/eclipse/etc. windows, anyway! On some of
the "real" X terminals, the root window may just be a solid color
(to let me determine which "desktop" I am using)
I run a small app (xanim, IIRC) that turns the cursor into a "twisting"
X (so it is easy to find). I use xeyes(1) to provide a quick hint as to
where I should go searching for the cursor ("Where are THEY looking?").
And some other (forget name) app that *hides* the cursor when it is
motionless for a period of time -- so I can freely type without
having the cursor interfere with the text I'm trying to read (as soon
as I nudge the mouse, the cursor rematerializes if I need specific
knowledge of it's location)
I use Windows-based apps for most of my "real work" -- desktop publishing,
schematic capture, PCB layout, analysis/simulation, etc. I run eXceed
on the PC to let me bring my NetBSD desktops onto the PC (I had previously
used NCDware as I purchased it to be compatible with some of my NCD X
terminals. But I have noticed that I tend to invoke the eXceed server
more often).
While NetBSD (and all the BSD's, for that matter) provide support for
the various desktops, window managers, "OpenOffice", etc. -- the usual
litany of FOSS products -- I don't run any of them as I have no real
need for them (having similar or better tools running under Windows
that all "play together" well).
I don't spend much (any!) time "updating" my Windows machines (nor
the *BSD ones, for that matter -- if it ain't broke, don't fix it!)
Seeing "products" like OpenOffice or KDE with new releases every few
months leads me to wonder if they have that many *problems* or if there
are that many MISSING FEATURES to necessitate so many releases! :<
I surely don't have that much "disposable time" to invest in downloading,
installing and debugging their latest set of features/bugs!
E.g., I went from NetBSD 3.1 to 5.something and will be building
these Atom's under whatever -CURRENT/STABLE happens to be (6.1.4?)
If you have an IT department available -- or, like to "play" with your
machines -- your preferences might be different.
These little Atom boxes, I am hoping, will allow me to replace larger,
power-hungrier boxes with smaller, more energy efficient ones -- without
too much of a sacrifice on performance. (I'm on a "downsizing binge"...
too much kit hiding here! :< ) And, move some of the external drives
that are currently hosted on specific Windows/BSD boxes off to a generic
NAS appliance (i.e., boot *that* box instead of some specific Windows
or BSD box to gain access to those files! At gigabit network speeds,
there's hardly any advantage to "local access" to those drives!)
Unfortunately, most of my machines use PATA, SCSI, SCA, or FC drives. Only
a couple of laptops (and one PC) use SATA drives. This leaves only the
laptop SATA's in some of my "external" drives as potential "sources" of
rotating media for the Atoms.
<http://www.apricorn.com/apricorn-bio-biometrically-secure-128-bit-aes-hardware-encrypted-hard-drive.html>
I'll see what I can come up with next week -- by way of drives *or*
something comparable to the Atom's (that, perhaps, uses PATA laptop
drives -- as I have many of those).
Meanwhile, I'm taking Andrew's suggestion and looking into (physically)
small USB thumb drives to host executables. I can prototype this sort
of operation with "regular" thumb drives and just move the images onto
physically smaller drives when the idea is "proven".
[toc] | [prev] | [next] | [standalone]
| From | mroberds@att.net |
|---|---|
| Date | 2014-09-18 19:33 +0000 |
| Message-ID | <lvfc2c$afu$1@dont-email.me> |
| In reply to | #18074 |
In sci.electronics.design Don Y <this@is.not.me.com> wrote: > I don't *think* these have integrated video. According to Wikipedia (would they lie to you?), the Atoms released in 2008 didn't have integrated video, but the later ones did. I think I was working with the "Pineview" [ND][45].. series chips, which did. > I tried booting a NetBSD system and the video quickly scrambled (hard > to see the dmesg output to determine which device was probed at the > time). I'll have to make some time to investigate... I haven't played with BSD much lately, but newer Linux distributions seem to compile the kernel to ask for something other than 80x25 text fairly early in the boot process - I think this is mostly so you can see more of the boot-time messages on the screen. If BSD is doing the same thing, perhaps that change is causing trouble. Linux has a "vga=" kernel boot parameter that lets you force a video mode. Linux also has a "console=" boot parameter that can give you a serial console if you want, and I think this happens early enough that it gets the kernel boot messages. Hook up your Teletype and party like it's 1969! :) The last time I played with BSD a lot, it was FreeBSD, and I got the impression that while the security and networking was better than Linux, the device support was not nearly as good as Linux. > Perhaps next step will be to try a *Windows* install if only to get > an enumeration of the various "devices" in the box! My checkout step was usually to boot a Linux live CD/DVD, using an external optical drive with its own power supply. In theory, you can put a bootable image on a USB stick, but I have found that the boot image, USB stick, BIOS, and phase of the moon must all align to get this to work right - the external optical drive was slower but much more likely to work. Matt Roberds
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2014-09-18 13:18 -0700 |
| Message-ID | <lvfesu$8ah$1@speranza.aioe.org> |
| In reply to | #18084 |
On 9/18/2014 12:33 PM, mroberds@att.net wrote: > In sci.electronics.design Don Y <this@is.not.me.com> wrote: >> I don't *think* these have integrated video. > > According to Wikipedia (would they lie to you?), the Atoms released in > 2008 didn't have integrated video, but the later ones did. I think I > was working with the "Pineview" [ND][45].. series chips, which did. From what I can gather looking at the "Setup" screen, this is an earlier series -- Diamondville -- Atom 330 (dual core, 1.6GHz, IA-64, Hyperthreading capable. *No* GPU (seems consistent from the number of heatsinks in the box) >> I tried booting a NetBSD system and the video quickly scrambled (hard >> to see the dmesg output to determine which device was probed at the >> time). I'll have to make some time to investigate... > > I haven't played with BSD much lately, but newer Linux distributions > seem to compile the kernel to ask for something other than 80x25 text > fairly early in the boot process - I think this is mostly so you can see > more of the boot-time messages on the screen. If BSD is doing the same > thing, perhaps that change is causing trouble. Linux has a "vga=" > kernel boot parameter that lets you force a video mode. No idea what the kernel on the Live CD that I was using was built as. Hence, the reason it's easier to just build a new one from scratch *knowing* what sort of cruft you've thrown into the pot. > Linux also has a "console=" boot parameter that can give you a serial > console if you want, and I think this happens early enough that it gets > the kernel boot messages. Hook up your Teletype and party like it's > 1969! :) <frown> Have to eBay the TTY soon. One more thing to get rid of. (last time I checked, folks were spending $1K on the silly things!) > The last time I played with BSD a lot, it was FreeBSD, and I got the > impression that while the security and networking was better than Linux, > the device support was not nearly as good as Linux. I started out with NetBSD back at v0.8. (maybe 1993?) Soon moved to FreeBSD (at the time, they were at 0.9, IIRC) because they were *solely* focused on i386 (NetBSD was pursuing many architectures concurrently -- admirable but meant getting an i386 box with the features that I wanted WORKING was more effort). Stayed there until about 2.2.7/8 (maybe 1998?). Then, disappointed with the falling quality (esp the ports/packages collection) -- and, having acquired a bit of larger iron (unsupported on FreeBSD) -- moved back to NetBSD. Which is where I have stayed, since (at least in terms of my own workstations/servers that run FOSS). >> Perhaps next step will be to try a *Windows* install if only to get >> an enumeration of the various "devices" in the box! > > My checkout step was usually to boot a Linux live CD/DVD, using an > external optical drive with its own power supply. In theory, you can > put a bootable image on a USB stick, but I have found that the boot > image, USB stick, BIOS, and phase of the moon must all align to get > this to work right - the external optical drive was slower but much > more likely to work. Yeah, I opted to boot from an external CD-ROM with a "live CD" than to bother installing a real system (actually, I didn't have a small enough disk drive to waste on the task :< ). I'll make a list of which boxes I can discard/replace in the event that these little things prove "suitable". Then, evaluate the effort to investigate more fully. (also gives me some time to round up smaller disk drives)
[toc] | [prev] | [next] | [standalone]
| From | Przemek Klosowski <przemek@tux.dot.org> |
|---|---|
| Date | 2014-09-21 12:34 +0000 |
| Message-ID | <lvmgju$rjm$1@dont-email.me> |
| In reply to | #18074 |
On Thu, 18 Sep 2014 00:28:45 -0700, Don Y wrote: > Perhaps next step will be to try a *Windows* install if only to get an > enumeration of the various "devices" in the box! Then, use that > information to build an appropriate kernel. I usually do the opposite: Linux tends to be better discovering everything that is visible to the processor. Between lspci, lsusb, dmidecode and kernel boot messages Linux is likely to see it all, whereas Windows tends to require installing specific drivers. This is by the way an advantage that the x86 platform holds over ARM: all peripherals tend to be on self-aware busses like PCI. On ARM everything is memory mapped so you do have to know register addresses and functions. Each platform then has to have a pre-written device tree description of its peripherals---there is no bare metal introspection.
[toc] | [prev] | [next] | [standalone]
| From | krw@attt.bizz |
|---|---|
| Date | 2014-09-21 11:54 -0400 |
| Message-ID | <o1tt1a1fbp9gcjd1b306fv34d9htiujkd8@4ax.com> |
| In reply to | #18178 |
On Sun, 21 Sep 2014 12:34:06 +0000 (UTC), Przemek Klosowski <przemek@tux.dot.org> wrote: >On Thu, 18 Sep 2014 00:28:45 -0700, Don Y wrote: > >> Perhaps next step will be to try a *Windows* install if only to get an >> enumeration of the various "devices" in the box! Then, use that >> information to build an appropriate kernel. > >I usually do the opposite: Linux tends to be better discovering >everything that is visible to the processor. Between lspci, lsusb, >dmidecode and kernel boot messages Linux is likely to see it all, whereas >Windows tends to require installing specific drivers. I don't remember the last time I had to "install" drivers in Windows. It does all that for me. It's been a while since I used Linux but it *never* worked without some serious tweaking, something I do *not* want to do. >This is by the way an advantage that the x86 platform holds over ARM: all >peripherals tend to be on self-aware busses like PCI. On ARM everything >is memory mapped so you do have to know register addresses and functions. >Each platform then has to have a pre-written device tree description of >its peripherals---there is no bare metal introspection. Different markets completely.
[toc] | [prev] | [next] | [standalone]
| From | edward.ming.lee@gmail.com |
|---|---|
| Date | 2014-09-17 08:10 -0700 |
| Message-ID | <f42f0d13-7a9f-4b06-b8b7-9f7ebcee3165@googlegroups.com> |
| In reply to | #18062 |
On Wednesday, September 17, 2014 1:21:35 AM UTC-7, mrob...@att.net wrote: > In sci.electronics.design Don Y <this@is.not.me.com> wrote: > > > Am I correct in assuming these are just "yet-another-x86"? > > Mostly. I think they are really a RISC CPU that pretends to be an x86 to the outside world. Intel learned from Itanic... yay backward compatibility! [0] > > > Are there any downsides/upsides/problems to watch for when porting desktop OS's/apps to these sorts of boards? > > At the time I was playing with a few of these (about 3-4 years ago), I was using Linux, and it was pretty much just "boot and go"; most of the onboard peripherals were standard enough that they just came up and worked. You could then run regular Linux apps (including X). My HP Atom laptop was built 5 years ago. It has Nivida ION graphic core build-in. It plays full HD video and mp4 well. > The exception was the video drivers. Out of the box, it wasn't any problem getting a text console and the "old standard" VGA modes, like 640x480, 800x600, 1024x768, and so on. If you wanted to run the graphics at full capability, though, you sometimes needed a driver from Intel or the SBC manufacturer, and you would run into the usual problem, which is that their unspecified "Linux driver" depended on a particular No, it works out of the box from standard kernel 3.14 and 3.15. > kernel version down to the ninth decimal place. I suspect as time marches on, more Linux distributions now ship with suitable drivers. But you still may need to "goose" the kernel with a boot-time command line option to get it to do the right thing. No, you don't.
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2014-09-17 15:11 +0000 |
| Message-ID | <lvc8an$m6g$1@reader1.panix.com> |
| In reply to | #18062 |
On 2014-09-17, mroberds@att.net <mroberds@att.net> wrote:
> In sci.electronics.design Don Y <this@is.not.me.com> wrote:
>> Am I correct in assuming these are just "yet-another-x86"?
>
> Mostly. I think they are really a RISC CPU that pretends to be an x86
> to the outside world.
Yep. That's exactly how Intel's x86 CPUs have been built for ages.
--
Grant Edwards grant.b.edwards Yow! Was my SOY LOAF left
at out in th'RAIN? It tastes
gmail.com REAL GOOD!!
[toc] | [prev] | [next] | [standalone]
Page 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web