[9fans] Scanners
Jorden Mauro
age of USB scanners: http://marc.info/?l=9fans&m=111558813208847&w=2
Has anyone given thought/attempted to getting newer scanners to work
on Plan 9? Perhaps the SANE library could be used as a base for
something saner (if you'll forgive the pun).
erik quanstrom
> on Plan 9? Perhaps the SANE library could be used as a base for
> something saner (if you'll forgive the pun).
i thought that was irony. :-)
- erik
Peter A. Cejchan
++pac
Andreas Zell
> nevertheless, nobody has a working scanner on plan9 ??
> ++pac
We have working scanner.
You can use the Wt25,WT36,Wt42/48 and WT36DS Scanner.
Scan via Touchscreen and upload the images to a Plan9 cifs
networkshare.
AZ.
Peter A. Cejchan
plan9 native box...
++pac
Peter A. Cejchan
this is from your web:
Requirement - Software: Java Sun Microsystems; Operating System
Windows 2000, Windows XP, Windows Vista
i got rid from those fsck-ing windoze os several yrs ago, now i want
to free last of my boxes still running linux...uggh
++pac
Jorden Mauro
Here's your irony:
P9 needs more APIs with TLAs and FLAs to make it more marketable.
Andreas Zell
> On Wed, Nov 25, 2009 at 1:20 PM, Peter A. Cejchan <tyap...@gmail.com> wrote:
>
> > if i understand it right, your scanner is NOT connected directly to a
> > plan9 native box...
>
> > ++pac
>
> this is from your web:
> Requirement - Software: Java Sun Microsystems; Operating System
> Windows 2000, Windows XP, Windows Vista
>
> i got rid from those fsck-ing windoze os several yrs ago, now i want
> to free last of my boxes still running linux...uggh
> ++pac
The scanner ist connect via 1G ethernet.
On the Touchscreen is an Option "Scan to network".
The scanner scans direct to a cifs share (aquarella on plan9).
No need for spezial software except a Cifs Server.
The scanner use smbclient.
AZ.
hiro
Jorden Mauro
Not a fun solution if you've already bought a scanner...
hiro
Peter A. Cejchan
Peter A. Cejchan
> The scanner use smbclient.
i repeat: i do not wish to have anything to do with windoze os, nor
with smb and other bullshit. sorry for such a rude wording... windoze
annoyed me along with other proprietary sw 20+ yrs.... i do share all
my outcome publicly... yes, i'm not a millionaire (and my outcome is
humble, YES), but several people already acknowledged my work... BTW,
if you read up to this point, i would design a book scanner in an
other way, especially, no parallel (to scanning lamp) covering glass,
but, rather, a roof-like glass construction *( to avoid book damage)
and a mirror + sw to convert it to rectangular page.... just my two
cents ;-)
sry if it's offending, but i'd like to see an open specification for
any , be it desktop, scanner. BTW, i consider supporting ONLY windoze
a violation of a free business contest law, IMHO....
sry 1 more, i just wted 2 know anybody uses a scnr on NATIVE p9....
++pac
ron minnich
> The scanner ist connect via 1G ethernet.
> On the Touchscreen is an Option "Scan to network".
> The scanner scans direct to a cifs share (aquarella on plan9).
> No need for spezial software except a Cifs Server.
> The scanner use smbclient.
That's neat. It makes sense too, using ethernet almost always seems a
better deal than using USB. It's so cheap to put a network stack and
ethernet into these devices, and the network stack is doubtless less
software than a USB stack ...
ron
Jack Norton
>> No need for spezial software except a Cifs Server.
>> The scanner use smbclient.
>
>
>
I checked out the image access site, and it looks like you can scan to
FTP, email (built in MTA?), along with the smb method.
I actually think thats pretty nice.
What on earth is free business contest law (FBCL I suppose)? Does that
mean if I only make parts for Ford motor cars, and I completely ignore
GM, and also the vast league of Kit Car DIY'ers, I am evil?
I like the book scanner idea though, you should jump on that. Much more
elegant in my opinion to the 'book open, face up' with camera's from
afar method.
-Jack
Brian L. Stuart
> > On the Touchscreen is an Option "Scan to network".
> > The scanner scans direct to a cifs share (aquarella on
> plan9).
> > No need for spezial software except a Cifs Server.
> > The scanner use smbclient.
>
> That's neat. It makes sense too, using ethernet almost
> always seems a
> better deal than using USB. It's so cheap to put a network
> stack and
> ethernet into these devices, and the network stack is
> doubtless less
> software than a USB stack ...
I definitely agree with this part of it. However, I would much
rather see the higher-level protocol be something that is simpler
and not tied to any commercial interests. I don't even object
to having cifs as an option. But when did it become popular
to say that ftp should not be an option for transferring a file?
BLS
John Floren
The basic little flatbed on the website can scan to FTP. I'm not sure
why the original poster chose to mention SMB and not FTP, but it's an
option.
Which is good, because I for one have never been able to get aquarela
working properly.
John
--
"Object-oriented design is the roman numerals of computing" -- Rob Pike
hiro
a web interface (but as you say, better than nothing).
Standards...
erik quanstrom
> better deal than using USB.
coraid agrees. except for the "almost" part.
- erik
Anthony Sorace
erik quanstrom
how to troll like a pro!
- erik
Brian L. Stuart
> popular
> > to say that ftp should not be an option for
> transferring a file?
>
> I'm not sure
> why the original poster chose to mention SMB and not FTP,
> but it's an
> option.
DOH! That's what I get for opening my mouth before checking
things out.
Sorry for the noise,
BLS
ron minnich
> where's my ethernet mouse? ;-)
I thought it was called drawterm.
ron
W B Hacker
> where's my ethernet mouse? ;-)
If Plan9 can 'plumb' a remote sound card, (a questionable example long
publicized) I'm sure it can do so with a mouse.
'Questionable example', as I've never quite understood how I'd be able to hear
the output of a sound card whose physically-attached speakers where half-way
round the world (can we also 'plumb' the analog audio?) - even before the Tet
'68 offensive took away much of my hearing.
;-)
Bill
Charles Forsyth
>publicized) I'm sure it can do so with a mouse.
it isn't plumbing, but export/import, and it's useful.
i had a usable sound system on my r3000 indigo, but my PC had none.
on the pc, i imported the indigo's /dev and played sounds that way.
i could imagine uses even a continent away (alarm system imports remote
/dev and announces trouble). next door might be more useful.
cinap_...@gmx.de
for plan9 right know. nobody seems to be working at one.
nobody cares if you dont like the solutions/hacks to the problem.
so just stop this thread and write a driver if you need one.
--
cinap
Anthony Sorace
// how to troll like a pro!
see, i was paying attention!
bill wrote:
// ...a questionable example...
if you have a lab of terminals but only one or two have a working
sound card and speakers, it can make good sense. first time i saw
that was a demo for something unrelated; we were in the real demo
before we'd realized what we'd done to get there.
W B Hacker
Welll - in the same room, it would seem 'sneakernet' would do well enough. Point
of fact, I use three kdb,vid,mouse and ... a swivel chair... less confusing than
sharing/switching among three disparate OS'en.
;-)
And I've actually considered remote audio I/O as part of a system for monitoring
a house that sits empty for months at a time, and responding to the doorbell ..
intrusion, et al ... but.. 'edge cases', both, if ever were. Easy enough to do
without Plan9. 'Too easy' to be fair.
'export/import' applied to remote resources - especially 'scarce' or expensive
ones (sound cards no longer are..) that could *send back* the results might make
a better present-day example.
If we could identify a few...
Couple of thoughts:
- hardware crypto devices (cheap and cheerful in recent VIA CPU, seldom seen
otherwise)
- fast, specialty (expensive) graphics processing engines for storage to file,
or streaming-back not (necessarily) remote display. Ray tracing comes to mind...
- a 'ration' - free or purchased - of grid or supercomputing resources? (several
experts here - I'm not among them)
In any case, given that audio codecs are near-as-dammit ubiquitous on commodity,
and even 'server grade' and 'embedded' system boards these many years, I think a
better example than sharing a Soundblaster-equivalent is overdue.
I'm well aware that 'marketing' Plan9 is not really on anyone's radar here ..
but there could be a bit more done to convey the availability and value to the
like-minded potential fellow-travelers [1]. One benefit might include more
current device driver import/devel..
JM2CW
Bill
[1] FWIW - the 'Blue Gene' Plan9 work deserves better publicity. If/as/when one
hears that a certain 'hobby' alleged-OS is being run on such expensive kit, one
tends to question why it was even built...
erik quanstrom
> ones (sound cards no longer are..) that could *send back* the results might make
> a better present-day example.
the resource i want is generally particuarly scarce;
there is often just one device that will do.
i often import the aoe device of a machine on a
storage network, for example. i think thinking
that all doo-dads with capability x are equivalent
is a mistake, or a misunderstanding of "capability".
> I'm well aware that 'marketing' Plan9 is not really on anyone's radar here ..
> but there could be a bit more done to convey the availability and value to the
> like-minded potential fellow-travelers [1]. One benefit might include more
> current device driver import/devel..
funny you should mention that.
- erik
W B Hacker
> erik wrote:
> // how to troll like a pro!
>
> see, i was paying attention!
>
> bill wrote:
> // ...a questionable example...
>
> if you have a lab of terminals but only one or two have a working
> sound card and speakers, it can make good sense.
I'm sure it did *at the time*...
But have you tried to find even an embedded nano board that has in-bridge-chip
audio codec's lately? Where 'lately' is now around ten years-plus? And
'speakers' have becoem tiny, effective - and also very cheap?
We've been chopping-off audio jacks on C3 & C7 MB for years to make quite decent
low-power 1U servers... too tall for the case otherwise.
PITA, that, but we don't use enough of 'em to order them 'unstuffed'.
> first time i saw
> that was a demo for something unrelated; we were in the real demo
> before we'd realized what we'd done to get there.
>
>
ACK .. but time marches on, and there *must* be a few 'shareable' things more
current than SB equivalents. How / why not get those examples onto the web page
as add-ons if not more germane replacements?
DISCLAIMER:
My audio gear largely sez 'Marantz' on the front panel, some dates as far back
as 1968, only the CD drive is newer than 1975, and CD aside, has SQRT-FA to do
with computers. Still sounds sweet though.
"Horses for courses"
Bill
W B Hacker
>> 'export/import' applied to remote resources - especially 'scarce' or expensive
>> ones (sound cards no longer are..) that could *send back* the results might make
>> a better present-day example.
>
> the resource i want is generally particuarly scarce;
> there is often just one device that will do.
>
> i often import the aoe device of a machine on a
> storage network, for example. i think thinking
> that all doo-dads with capability x are equivalent
> is a mistake, or a misunderstanding of "capability".
There you go. A better example, IMNSHO, than SB16-equiv.
And there just *have to be* another dozen 'modern' examples lying about.. taken
for granted by 9fans perhaps - but there's the rub...
Hiding a whole light-show under a bushel, if you will.
...meanwhile, other newcomers are involved in reinventing the networking,
clustering, 'sharing' capability - and not necessarily all that well - that
Plan9 started life with...
>
>> I'm well aware that 'marketing' Plan9 is not really on anyone's radar here ..
>> but there could be a bit more done to convey the availability and value to the
>> like-minded potential fellow-travelers [1]. One benefit might include more
>> current device driver import/devel..
>
> funny you should mention that.
>
> - erik
>
>
Sad to say, all the drivers I have ever written were in octal, ASM, or LMI Forth
(with ncc), so I'm not in any way 'current' myself.
But it IS a bit frustrating to see drivers available in one F/OSS OS (or
variant) and not another, more especially as they are nearly always written in
reasonably portable 'C' code these many years.
Reality is that the rate of introduction/change of hardware/silicon is too fast
for any small - or even 'medium sized' team (FreeBSD for example) to keep up
with on their own... and that gap is widening.
Bill
erik quanstrom
> variant) and not another, more especially as they are nearly always written in
> reasonably portable 'C' code these many years.
that's easier said than done. Blocks are not the same as sk_bufs.
for that matter, they're not the same as MsgBufs or RingBufs.
> Reality is that the rate of introduction/change of hardware/silicon is too fast
> for any small - or even 'medium sized' team (FreeBSD for example) to keep up
> with on their own... and that gap is widening.
that's only a problem if one's goal is to support all possible
hardware.
- erik
Sam Watkins
like pair-programming over then internet, if you are working on an app or game
that uses sound.
Sam
Sam Watkins
interface that would support loading linux modules into whatever other OS such
as Plan 9. I suppose it would be vastly simpler than something like "wine" for
example. I think that would be useful, because so many devices are supported
under linux before other OSes. I'm not experienced at kernel programming, so
there may be issues with memory mappings and such that would make it impossible
to get some modules working in this fashion. I guess it might be possible
though.
Sam
Sam Watkins
> I don't know how hideously complicated it would be, to implement a module
> interface that would support loading linux modules into whatever other OS
> such as Plan 9.
also perhaps it would be possible to run modules in userland, again drivers
needing access to direct memory-mapped devices and not doing that through the
kernel might be a problem.
Sam Watkins
> also perhaps it would be possible to run modules in userland, again drivers
> needing access to direct memory-mapped devices and not doing that through the
> kernel might be a problem.
sorry for repeated posting! apparently this "DUSK" project is relevant:
http://www.slideshare.net/alexeysmirnov/dusk-develop-at-userland-install-into-kernel
W B Hacker
>> But it IS a bit frustrating to see drivers available in one F/OSS OS (or
>> variant) and not another, more especially as they are nearly always written in
>> reasonably portable 'C' code these many years.
>
> that's easier said than done. Blocks are not the same as sk_bufs.
> for that matter, they're not the same as MsgBufs or RingBufs.
Aware.
But take note of Haiku's move to make their OS capable of using *BSD drivers.
That sort of adapter layer seems worthwhile, even if the results do not
initially approach 'native' performance.
*After* the dust settles (who woulda thunk, on apparent 'merit' or lack thereof,
that the dodgy Realtek silicon would ever have become soooo ubiquitous?)
..THEN 'native' drivers could be gone after for the much smaller subset of
'common survivors'. IOW, better a slow, or feature-stripped driver than none at
all.
>
>> Reality is that the rate of introduction/change of hardware/silicon is too fast
>> for any small - or even 'medium sized' team (FreeBSD for example) to keep up
>> with on their own... and that gap is widening.
>
> that's only a problem if one's goal is to support all possible
> hardware.
>
> - erik
>
>
Not a goal I'd seek - nor even lcose to it.
It is not really a problem if, for example, one says there is only a VESA 2 (or
later) driver for video - so long as it is a good one, as Plan9 is not really a
GUI-centric OS in the first place. More akin to ncurses with a precocious mouse.
;-)
Bill
W B Hacker
VNC can (has been) be a butt-saver' - but pales in comparison to remote desktop
/ remote X for relative responsiveness and seamlessness.
(And we are speaking cross-platform, as Plan9 <=> Plan9 doesn't necessarily need
either..)
Bill
Charles Forsyth
> interface that would support loading linux modules into whatever other OS
> such as Plan 9.
only as hideously complicated as the linux kernel interfaces might be,
but sadly those are indeed hideously complicated. try tracing the source
of a driver you care about (because that's the only way to help guess how
the undocumented hardware might work). good luck. see you later. (much later.)
Charles Forsyth
>for any small - or even 'medium sized' team (FreeBSD for example) to keep up
>with on their own... and that gap is widening.
that's not usually the biggest problem, although it's true that lack of time
can be a problem: it's the lack of (reasonably) accurate
documentation (independent of the source of some convoluted driver written by
someone who clearly doesn't do it for fun).
in the days when you could download a register-level description from
such-and-such a manufacturer, given enough incentive it was only a matter of time
and effort to drive the chip. now, a fairly non-trivial psychic ability is needed too.
i don't know why i'm replying to these. this topic has been re-hashed
periodically, and if anyone is keen actually to implement any of these helpful bits of advice
to test their ideas, i'm sure iwp9 would be a great venue to show the results.
Ethan Grammatikidis
Indeed. Overheard in #plan9 recently: "Reading Linux driver source
code is where the fun stops." This may vary by device type, I think I
heard Linux framebuffer driver source was most useful to developers
of one OS.
Ethan Grammatikidis
Another useful example is drawterm.
erik quanstrom
> I don't know how hideously complicated it would be, to implement a module
> interface that would support loading linux modules into whatever other OS such
> example.
letting along problems of cross compliation from gcc, or whatever,
you'd still be wrong. the internal linux apis change with every . release.
- erik
erik quanstrom
>
> That sort of adapter layer seems worthwhile, even if the results do not
> initially approach 'native' performance.
>
> *After* the dust settles (who woulda thunk, on apparent 'merit' or lack thereof,
> that the dodgy Realtek silicon would ever have become soooo ubiquitous?)
>
> ..THEN 'native' drivers could be gone after for the much smaller subset of
> 'common survivors'. IOW, better a slow, or feature-stripped driver than none at
> all.
i have known about haiku (and a few other oses) using bsd drivers.
i'm sure that most everyone who writes drivesrs for plan 9 knows about
this too.
one of the chief advantages of plan 9 is that it can be understood by
one person. if you drag sk_bufs and all that other goo into the kernel,
you dimish one of plan 9's chief advantages by a considerable amount.
also there is a lot to be gained by writing one's own driver. it pays to
understand the hardware, especially if you depend on it. you may
have to fix some critical bugs. i know some of the hardware that coraid
uses has some fixes that i know linux does not have.
useless observation:
it's fun to see the linux guys bragging about how their drivers are so
small. bsd drivers are typically half their size. plan 9 drivers are typically
half again as large. to be fair, plan 9 drivers typicall give up things like
tso.
- erik
W B Hacker
*snip*
>
> useless observation:
> it's fun to see the linux guys bragging about how their drivers are so
> small. bsd drivers are typically half their size. plan 9 drivers are typically
> half again as large. to be fair, plan 9 drivers typicall give up things like
> tso.
>
> - erik
>
>
'half again as large' ?? or half the *BSD size?
And no - not at all 'useless' information.
To anyone accustomed to ASM or Forth, smaller (and still functional, of course)
indicates a better understanding of the task at hand, more throurough
exploration of the 'needfuls', and more effort sweating-out whatever desn't add
value. Worthwhile, all.
'Useless' OTOH, would be to try to use moving-kludge-Linux drivers as a model.
I'd sooner recommend OpenBSD or NetBSD. Better average quality, more long-term
consistent interfaces.
erik quanstrom
half the size
> I'd sooner recommend OpenBSD or NetBSD. Better average quality, more long-term
> consistent interfaces.
i have no interest. the compatability stuff will likely
be as large as the current port directory.
- erik
Anthony Sorace
mentor's summit for non-linux OS users (good meeting, although not quite as
amusing as the "Troll Like a Pro" session). the folks at the meeting all thought
their biggest problem was lack of driver support, and the Rosetta group is an
effort to define a way to address that.
they kinda started by re-defining UDI without realizing it, but since have. the
group was dominated by *bsd folks, but we're not the only oddballs involved.
we'll see if we can get anything useful out of it. hopefully something more
manageable than UDI.
W B Hacker
Given that the four BSD's don't even grok each other's disklabels or UFS all
that well, I'll not hold my breath while awaiting miracles...
Given FAT(n)'s limitations, it is a tad ironic that one of the more 'universal'
fs (long name, case-sensitive, and UTF-8 capable) with which to share portable
HDD/flash between and among Mac and all of the other *BSD's is ...
ext2...
:-(
.. and perhaps Fossil?
;-)
Bill
lu...@proxima.alt.za
> heard Linux framebuffer driver source was most useful to developers
> of one OS.
As a NetBSD user, I found the ISDN drivers in Linux considerably
easier to read than the FreeBSD ones (NetBSD didn't include them at
the time). I think NetBSD's philosophy of drawing a very clear
boundary between machine-dependent and machine-indepndent comes
closest to Plan 9; unfortunately, NetBSD is a bit more strict in its
application: Plan 9 prefers the device drivers to be entirely in the
machine-dependent space. Bottom line, both NetBSD and Plan 9 take
their philosophy too far and neither can learn from the other.
Which is why Linux drivers become the examples to follow :-)
++L
ron minnich
> letting along problems of cross compliation from gcc, or whatever,
> you'd still be wrong. the internal linux apis change with every . release.
They change basically biweekly. It's not fun and it's not fun to find.
We once had a 2-line change to the mmu code subtly break our own
driver, which subtly broke an HPC machine. Not fun at all.
ron
matt
I have an agfa 1212u which is USB.
I got a USB sniffer for Windows and the SANE code and was going through
it byte by byte. I had it uploading the firmware and could make the
scanning arm move.
/n/sources/contrib/maht/spanscan.iso
I think I might even have it doing preview scan but not interpreting the
data, I forget, it was two years ago.
another one of those things on the list of 'I must go back to that'
If anyone knows of a decent free USB sniffer for Linux / BSD then that
would help anyone wanting to do this.
Matt
Tim Newsham
> i had a usable sound system on my r3000 indigo, but my PC had none.
> on the pc, i imported the indigo's /dev and played sounds that way.
> i could imagine uses even a continent away (alarm system imports remote
> /dev and announces trouble). next door might be more useful.
I personally would like to see a lot more in the way of remote
resource access using 9p and I'm working towards that by writing
software for windows, linux and android. Its a slightly different
use case than typical plan9 setup: ie my terminal has some
devices and I push them to a cpu server so programs run there
can access local resources. Instead you have resources on several
machines that you own (and who doesnt own several machines these
days, heck even my non-tech relatives do) and you import them
to use them as necessary. I've been playing around with sound
a lot as a starting point but I am hoping to move on to other
devices soon. In my current prototypes I can import sound devices
from (android, windows, linux oss) onto another (android, windows,
linux oss) machine and either replace the current audio subsystem
or offer the remote audio as an additional audio device.
Why should all of your machines need a dvd drive, sound card, sdcard
reader, etc.?
Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
erik quanstrom
> reader, etc.?
or the cannonical example, a hard drive.
- erik
Tim Newsham
> resource access using 9p and I'm working towards that by writing
> software for windows, linux and android. Its a slightly different
> use case than typical plan9 setup: ie my terminal has some
I meant to add here that the planB guys probably have some
experience here that would be worth hearing.
Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
Tim Newsham
I intentionally avoided this one because two things that modern
OSs do know how to share (at least a little) are:
- filesystems
- printers
Its just all the other stuff that they haven bothered to tackle
yet, except in very specific applications (ie. remote desktop access).
> - erik
Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
erik quanstrom
> > or the cannonical example, a hard drive.
>
> I intentionally avoided this one because two things that modern
> OSs do know how to share (at least a little) are:
> - filesystems
> - printers
it is pretty hard to run windows, osx or linux without
ron minnich
> it is pretty hard to run windows, osx or linux without
> a hard drive.
linux is actually quite easy and has been for about 12 years or more
... not sure of the others.
ron
Francisco J Ballesteros
in the octopus. we'll be happy to
discuss any of it.
> [/mail/box/nemo/msgs/200911/1912]
Lyndon Nerenberg VE6BBM/VE7TFX
> ... not sure of the others.
I was running diskless Windows in 1995; it wasn't pretty, but it could
be done. These days you can run XP+ diskless if you have the right
Windows Server and installation tools fu.
W B Hacker
>> or the cannonical example, a hard drive.
>
> OSs do know how to share (at least a little) are:
> - filesystems
> - printers
>
> yet, except in very specific applications (ie. remote desktop access).
>
>> - erik
>
> Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
>
>
Actually, they have ...
'Big iron' quite aside [1], it was common (at least) as far back as CP/M 2.X to
share peripherals such as prom-blasters, text-to-speech gear, terminals, serial
and parallel ports across multiple machines. Not everything needed was in the
as-shipped 'OS', but it was not hard to code the rest.
By the time Netware, IBM OS/2 (and perhaps Win-?? - not my area of expertise)
came along it was tick-the-box easier to share, for example, a modem or scanner,
just as easily as a printer or storage device. IOW - streaming 'near real time'
devices as well as spooled or (actual) file-based services.
Plan9 didn't 'invent' any of this.
Plan9 just prioritized it and provided a more appropriate infrastructure and
toolset to make for easier and more ubiquitous use of it all.
That one or more folks are now seeing a need to reinvent that particular set of
wheels is curious, as it never actually went away - Plan9 or otherwise.
Perhaps the old saw about 'ethnics' (pick yer own favorite..) and garbage.
"We never actually throw anything away, we just kick it from place to place
until its gets lost."
Bill
[1] AN/FSQ-7 and AN/GSA-51, could of course 'share' their resources - or at lest
take-over, one from another. But that sort of thing has been MIL-SPEC since
about 8,000 years before a certain French Colonel of Dragoons gave up his
military career to lay the groundwork for the Plan9 user interface.
W B Hacker
Don't get me started on diode plugboard 'ROM', mercury or nickel-iron delay
lines and 'upgrading' to mag drum memory now...
Time was when a power user's *personal* computer (~US$ 25,000+ in 1968-69
dollars [1]) had the full-house complement of RAM it could hold.
All 8 kilobytes of it.
;-)
.. and we controlled satellites and serious weapons systems with those as well
as digitizing electro cardiograms and such.
More seriously - there's another probable reason Plan9 hasn't found greater take-up.
No need to share when there are enough sheep to go around...
Bill
[1] For which price one could buy anywhere from four to twelve new automobiles
at the time.
Enrico Weigelt
Linux runs fine diskless. Done it already 15 years ago ...
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: wei...@metux.de
mobile: +49 174 7066481 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
matt
I've done Linux over AoE, that was flawless once working. Lack of AoE
aware installers made it interesting.
Plan9 is a fiddle too
I didn't try the MacOSX or Windows AoE initiators.
You need plenty of Foo to do any of them tbh.
Enrico Weigelt
Hi,
> Has anyone given thought/attempted to getting newer scanners to work
> on Plan 9? Perhaps the SANE library could be used as a base for
> something saner (if you'll forgive the pun).
IMHO the first good step would be teaching SANE to speak 9P
(as replacement for its own protocol), then split it off into
several packages - moving drivers to their own processes and
step by step port the whole thing to Plan9 (maybe through the
linux emulation).
Maybe this could be combined with my suggested 9P camera stuff ;-)
matt
/n/sources/contrib/maht/snapscan.iso
if you didn't work out the typo
Enrico Weigelt
> > linux is actually quite easy and has been for about 12 years or more
> > ... not sure of the others.
>
> be done. These days you can run XP+ diskless if you have the right
> Windows Server and installation tools fu.
Yep. Around that time we ran diskless win-3.x and win95 via Novell.
A bit tricky to setup, but it worked.
Enrico Weigelt
> where's my ethernet mouse? ;-)
Well, it already would be a good start if mice spoke 9P ;-)
(actually, that's what we're going to do on software/driver
side in the gpm-ng project)
Enrico Weigelt
> lines and 'upgrading' to mag drum memory now...
This is one of the days when this list feels like an veteran meeting ;-)
I'm probably one of the youngest here, i didn't have the honour to do
my first steps on punchtapes ;-o
Enrico Weigelt
Hi,
> I personally would like to see a lot more in the way of remote
> resource access using 9p and I'm working towards that by writing
> software for windows, linux and android.
actually, that's also my primary focus here. Not the OS itself,
but carry the amazing concepts to other worlds.
> I've been playing around with sound a lot as a starting point
> but I am hoping to move on to other devices soon.
Great! Do you have any (maybe usable) code yet ?
Enrico Weigelt
Hi,
> I don't know how hideously complicated it would be, to implement
> a module interface that would support loading linux modules into
> whatever other OS such as Plan 9.
Wouldn't it be easier (and maybe more robust) to run an specially
tailored linux kernel in an VM ? Something like Xen guests with
PCI devices routed to them ?
erik quanstrom
> >a hard drive.
> >
> >
> I've done Linux over AoE, that was flawless once working. Lack of AoE
> aware installers made it interesting.
>
> Plan9 is a fiddle too
>
> I didn't try the MacOSX or Windows AoE initiators.
>
> You need plenty of Foo to do any of them tbh.
i wasn't talking about aoe. but since you are, what
exactly is difficult about the plan 9 aoe driver?
- erik
Tim Newsham
>> but I am hoping to move on to other devices soon.
>
> Great! Do you have any (maybe usable) code yet ?
I have lots of code, but its unpublished proprietary at
this point (aside from the bits that I've released on this
mailing list).
> cu
Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
W B Hacker
> * W B Hacker <w...@conducive.org> wrote:
>> Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
>> lines and 'upgrading' to mag drum memory now...
>
> This is one of the days when this list feels like an veteran meeting ;-)
> I'm probably one of the youngest here, i didn't have the honour to do
> my first steps on punchtapes ;-o
>
>
> cu
Heh!
If you'd ever dropped a deck of punched *cards* you'd have thought paper tape
was a huge advance, and more durable mylar even more so....
;-)
Wasn't all that slow, either. Mannesman-Tally punched it at 300 cps and upwards,
many optical readers read it back at over 1,000 cps.
Enrico Weigelt
> >>but I am hoping to move on to other devices soon.
> >
> >Great! Do you have any (maybe usable) code yet ?
>
> I have lots of code, but its unpublished proprietary at
> this point (aside from the bits that I've released on this
> mailing list).
maybe you could put it into an git repo and publish it ?
matt
>i wasn't talking about aoe. but since you are, what
>exactly is difficult about the plan 9 aoe driver?
>
>- erik
>
>
>
so far and decided on a "better way" which is on my large pile of todo.
I made a "install to this drive" script that did away with the installer
completely but I haven't tested it much yet.
erik quanstrom
good point. i'll take a look at that. installing isn't
something i typically do. let alone onto aoe.
really just need to add a configure drive step.
- erik
Ethan Grammatikidis
I think this sharing dropped off drastically at some point in fairly
recent history. I took a look at Apple's list of services and devices
which can be shared with a checkbox or two; it really was a much
shorter list than I thought, and I'm sure the most convenient Linux
distro has a couple less items again.
Windows I'm not so sure about, but I don't think you have to go back
many years to find the time when Windows 98 was the most common
Windows, and what did that offer to share? Printers and files only,
if I remember right.
Ethan Grammatikidis
It's certainly possible to run OS X diskless, and knowing Apple it'll
take less setting up than Linux. ;)
hiro
about it's elegance or simplicity? I don't remember what my toaster
has to do with 9p, but nevermind.
Ethan Grammatikidis
On 28 Nov 2009, at 2:28 pm, hiro wrote:
> It's also very easy to run my toaster diskless. Does this say anything
> about it's elegance or simplicity? I don't remember what my toaster
> has to do with 9p, but nevermind.
And somebody always mentions toasters! Or coffee machines... :D
Actually, yes it does say a lot about a toaster's elegant simplicity:
a toaster only has parts to do the job intended. At a minimum a
switched heater, a sprung sliding bread carrier which also switches
the heater, and a thermally-releasing latch for the slider. I have
seen a toaster without even that much complexity; it had glass sides
so you could see when your toast was done how you like it.
Actually there is a link here. Things to share are increasingly
bloated, and applications strangely seem to need access to every
feature of the shared entity. 9p could perhaps help by presenting a
device model with files for different capabilities, or something like
that, but it is only half a solution. OTOH perhaps the need to access
device features is not really strange. Requiring a whole postscript
interpreter on your printer could be seen as just as strange, it was
certainly very expensive to do a few years ago.
Jorden Mauro
<eek...@fastmail.fm> wrote:
>
> On 28 Nov 2009, at 2:28 pm, hiro wrote:
>
>> It's also very easy to run my toaster diskless. Does this say anything
>> about it's elegance or simplicity? I don't remember what my toaster
>> has to do with 9p, but nevermind.
>
> And somebody always mentions toasters! Or coffee machines... :D
>
> Actually, yes it does say a lot about a toaster's elegant simplicity: a
> toaster only has parts to do the job intended. At a minimum a switched
> heater, a sprung sliding bread carrier which also switches the heater, and a
> thermally-releasing latch for the slider. I have seen a toaster without even
> that much complexity; it had glass sides so you could see when your toast
> was done how you like it.
There is a toaster that burns a picture of a raincloud, sun,
snowflake, etc. depending
on the morning's forecast. There is also a coffee pot you can control
via ethernet.
The coffee pot runs windows and there is a virus that causes Coffee
Denial of Service
on it.
Steve Simon
> working properly.
I have used it quite a few times in the past. however every so often
I do find some weird part of the SMB spec which is not implemeted. That
said it usually works well.
I am happy to look at reports of problems as I have had dealings with
the CIFS protocol in the past.
-Steve
Steve Simon
> / remote X for relative responsiveness and seamlessness.
My experience of serving a Windows desktop to a plan9 terminal
is that TightVNC with the DFMirage "Mirror driver" works really well.
-Steve
Ethan Grammatikidis
I've had responsiveness issues when the viewing machine hasn't enough
CPU power to decode the screen data in real-time. A lot of power
seems to be needed, my PDA, a 416MHz ARM can't cope with any
compression at all, I have to limit vncviewer to copyrect and raw
encodings only. Encoding doesn't seem to need half as much CPU power.
I ran Xvnc on a headless server with a 400MHz AMD K6 with no issues
that I recall.
All that gear was using either TightVNC or the plain vnc-x.y.z.tar.gz
from RealVNC. When using Vine Server on a 466MHz Apple screen updates
are not really adequate, while the mouse pointer lags if I use the
VNC server supplied with OS X Tiger on the same machine. x0vncserver
is a known problem server which I haven't used, IIRC it basically
works by taking screenshots continuously and sending those.
Patrick Kelly
On Dec 1, 2009, at 17:28, Ethan Grammatikidis <eek...@fastmail.fm>
wrote:
>
> On 1 Dec 2009, at 8:44 pm, Steve Simon wrote:
>
>>> VNC can (has been) be a butt-saver' - but pales in comparison to
>>> remote desktop
>>> / remote X for relative responsiveness and seamlessness.
>>
>> My experience of serving a Windows desktop to a plan9 terminal
>> is that TightVNC with the DFMirage "Mirror driver" works really well.
>
> I've had responsiveness issues when the viewing machine hasn't
> enough CPU power to decode the screen data in real-time. A lot of
> power seems to be needed, my PDA, a 416MHz ARM can't cope with any
> compression at all, I have to limit vncviewer to copyrect and raw
> encodings only. Encoding doesn't seem to need half as much CPU
> power. I ran Xvnc on a headless server with a 400MHz AMD K6 with no
> issues that I recall.
Now I don't have any expertise with VNC, but decoding anything, is
supposed to take less time than encoding it. I would check into that.
Sam Watkins
>I've had responsiveness issues when the viewing machine hasn't enough CPU
>power to decode the screen data in real-time. A lot of power seems to be
>needed, my PDA, a 416MHz ARM can't cope with any compression at all, I have
>to limit vncviewer to copyrect and raw encodings only.
The Java tightvnc client works fine on my little eee pc, so I would think the
native client should run well enough on a toaster. Maybe it uses floating
point and the ARM pda in question doesn't have hardware floating point.
Sam
Tim Newsham
> in the octopus. we'll be happy to
> discuss any of it.
Did you find 9p adequate for the resource sharing you
did or did you have to alter the protocol or augment it
with other protocols?
Did you use the normal plan9 authentication mechanisms or
did you explore other authentication alternatives? Were
all machines in a shared authentication domain or did you
support multiple authentication domains?
What did you do about machine or resource discovery?
Is there a mechanism to discover when machines or resources
are added or removed from the network?
What papers do you recommend looking at?
Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
Ethan Grammatikidis
Java sometimes does turn up trumps where C code struggles on machines
which were recently considered powerful. Other examples would be web
browsing and Flash video. Now the web supports alternative style
sheets to present a simpler layout on mobile devices and Flash
supports a supports a video format which takes less work to decode -
YouTube offers it as an option. Perhaps the Java TightVNC client
declines the trickier encodings, exactly as I have to pass options to
the C client to do. By default the C TightVNC and RealVNC clients
assume "we can has cycles," which leaves me wondering quite what
situations have sufficient computing power with such measly bandwidth
as to make the 'heavy' encodings worthwhile.
Sorry for the late reply, had to ignore email to get other things in
order.
--
freedesktop.org, because unix doesn't make things harder enough.
Ethan Grammatikidis
eek...@fastmail.fm
erik quanstrom
> which were recently considered powerful. Other examples would be web
what?
- erik
Jorden Mauro
wrote:
>> Java sometimes does turn up trumps where C code struggles on machines
>> which were recently considered powerful. Other examples would be web
>
> what?
>
Could be talking about GC? I saw a paper once that described speedups
in X11 when hooked up to the Boehm collector.
I'm always sceptical about these kinds of claims.
Anthony Sorace
from the rest of his post, i gather that the claim isn't that Java vs.
C code of equivalent
quality has C lagging, but rather that some application written in
Java can beat an
application of vaguely equivalent description written in C. the VNC
examples given
say, basically, that the Java app performs better out of the box than
the C app, but it
seems to just be about picking better (for that particular case)
defaults.
i guess my question is really what this observation is intended to
illustrate.
Ethan Grammatikidis
Yes, that would be what I meant. Thanks for writing that Anthony,
these things are all pretty clear in my head, but writing them out
clearly is quite hard work.
--
Ethan Grammatikidis
eek...@fastmail.fm
Enrico Weigelt
> It's also very easy to run my toaster diskless.
hmm, I think the Toasters work w/ SSDs or maybe some kind of
nano corememory, at least the mechanical ones. This could also
their extreme suspectibility to certain radiations. But no idea
what causes that effect on the humanoid ones ... ;-o
Enrico Weigelt
> I saw a paper once that described speedups
> in X11 when hooked up to the Boehm collector.
hmm, do you know how did it and if there's any code on that yet ?
Enrico Weigelt
> The coffee pot runs windows and there is a virus that causes Coffee
> Denial of Service on it.
That, of course, would be the very most worstcase that can ever happen ;-)
Patrick Kelly
> * Jorden Mauro <jrm...@gmail.com> wrote:
>
>> The coffee pot runs windows and there is a virus that causes Coffee
>> Denial of Service on it.
>
> That, of course, would be the very most worstcase that can ever
> happen ;-)
I doubt anyone would be foolish enough to put an 80x86 in a coffee
machine. Yes you could run WinCE, but without the 80x86 your not going
to suffer from the hoards of virus's.
I'd like to see the day someone gets Linux or NetBSD booting on a
coffee machine.
LiteStar numnums
On Jan 5, 2010, at 6:52 AM, Enrico Weigelt <wei...@metux.de> wrote:I doubt anyone would be foolish enough to put an 80x86 in a coffee machine. Yes you could run WinCE, but without the 80x86 your not going to suffer from the hoards of virus's.
* Jorden Mauro <jrm...@gmail.com> wrote:
The coffee pot runs windows and there is a virus that causes Coffee
Denial of Service on it.
That, of course, would be the very most worstcase that can ever happen ;-)
I'd like to see the day someone gets Linux or NetBSD booting on a coffee machine.
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: wei...@metux.de
mobile: +49 174 7066481 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
--
And in the "Only Prolog programmers will find this funny" department:
Q: How many Prolog programmers does it take to change a lightbulb?
A: No.
-- Ovid
"By cosmic rule, as day yields night, so winter summer, war peace, plenty famine. All things change. Air penetrates the lump of myrrh, until the joining bodies die and rise again in smoke called incense."
"Men do not know how that which is drawn in different directions harmonises with itself. The harmonious structure of the world depends upon opposite tension like that of the bow and the lyre."
"This universe, which is the same for all, has not been made by any god or man, but it always has been, is, and will be an ever-living fire, kindling itself by regular measures and going out by regular measures"
-- Heraclitus
hiro
Jorden Mauro
>
>> * Jorden Mauro <jrm...@gmail.com> wrote:
>>
>>> The coffee pot runs windows and there is a virus that causes Coffee
>>> Denial of Service on it.
>>
>> That, of course, would be the very most worstcase that can ever happen ;-)
>
> I doubt anyone would be foolish enough to put an 80x86 in a coffee machine.
> Yes you could run WinCE, but without the 80x86 your not going to suffer from
> the hoards of virus's.
You have too much faith in humanity. It runs on a Via x86 clone:
http://www.microsoft.com/presspass/features/2009/jan09/01-09cesfugoo.mspx
The article doesn't mention which flavor of Windows, but I don't think
WinCE runs on x86, does it?
>
> I'd like to see the day someone gets Linux or NetBSD booting on a coffee
> machine.
Seconded.
Patrick Kelly
On Jan 8, 2010, at 10:29 AM, hiro <23h...@googlemail.com> wrote:
> They are running apache on a toaster? My goodness.
>
Way too powerfull of a toaster.
Overkill ftw!