Re: [9fans] 9pi + apple keyboard
On Sat, Jan 26, 2013 at 07:12:50AM -0500, erik quanstrom wrote: > > > ; >/dev/null time factor 281476419553081 > > > 146.60u 0.01s 148.24rfactor 281476419553081 > > > ; >/dev/null time /sys/src/cmd/5.factor 281476419553081 > > > 1.20u 0.01s 1.22r/sys/src/cmd/5.factor 281476419553081 > > > > Umh how does 'factor' relate to a FPU? > > I don't have a plan9 running there, but the gnu 'factor' runs in 2.2s in > > a raspberrypi, and 0.05s in a sheevaplug, here. > > factor on plan 9 uses floating point heavily. rpi has floating point > hardware, and the sheeva plug does not. (at least according to > the nda docs on the processor i read.) Ah, all clear. Thank you! I just thought of some discrepancy that can happen around linux/gnu, that could be applied in your example. On a processor without FPU, these two situations can happen with code that uses floating point operations: - run code with FPU instructions, emulated by the kernel through exceptions - run code compiled without FPU instructions, with floating point as non-FPU code. The former runs quite slower than the latter. > > > (burncycles calculates the digits of pi using a taylor series > > > expansion. it uses all the tricks in the book to generate as > > > few bits of the result per cycle possible, without being verbose, > > > obtuse, or off task. obviously, it was an accident. > > > the very fast machines have the advantage of non-emulated > > > vlongs, running amd64 kernels) > > > > What are these emulated vlongs? Would that mean an atom computer would run > > relevantly faster i686 code over x86_64 code? > > i think i said the opposite. amd64 code heavily running vlongs > would run faster in long (64-bit) mode. this is because since the registers > are 64-bit wide, normal 64-bit arithmatic can be computed directly > with machine instructions. with a 32-bit machine, the compiler needs > to emulate a 64-bit operation since the registers available are not wide > enough. > > (iirc, there were no atoms in 64-bit mode in the list.) Ok, thank you very much! I understood as if you had listed a 64-bit mode atom, and these having some peculiar implementation of 64-bit operations (as too slow microcode or something like that. Best regards, Lluís.
Re: [9fans] 9pi + apple keyboard
On Wed, Jan 23, 2013 at 04:10:48PM -0500, erik quanstrom wrote: > On Wed Jan 23 10:49:47 EST 2013, quans...@quanstro.net wrote: > > > Interesting results, thank you! > > > The difference between the Pi and the Sheeva is quite huge, > > > I wasn't excepting such difference. This seems to confirm my > > > initial thoughts regarding the Atom perfs. > > > > that's just for floating point, which the sheeva doesn't have. > > the newer model from the same line does have floating point: > > > > http://www.globalscaletechnologies.com/p-58-mirabox-development-kit.aspx > > richard, thanks for the floating point. this is good stuff. > this is better than 100x faster: > > ; >/dev/null time factor 281476419553081 > 146.60u 0.01s 148.24rfactor 281476419553081 > ; >/dev/null time /sys/src/cmd/5.factor 281476419553081 > 1.20u 0.01s 1.22r/sys/src/cmd/5.factor 281476419553081 Umh how does 'factor' relate to a FPU? I don't have a plan9 running there, but the gnu 'factor' runs in 2.2s in a raspberrypi, and 0.05s in a sheevaplug, here. > (burncycles calculates the digits of pi using a taylor series > expansion. it uses all the tricks in the book to generate as > few bits of the result per cycle possible, without being verbose, > obtuse, or off task. obviously, it was an accident. > the very fast machines have the advantage of non-emulated > vlongs, running amd64 kernels) What are these emulated vlongs? Would that mean an atom computer would run relevantly faster i686 code over x86_64 code? Regards, Lluís.
Re: [9fans] 9pi + apple keyboard
On Wed, Jan 23, 2013 at 10:36:52AM +, Richard Miller wrote: > > the rpi is only half as fast as a sheeva plug. > > ... half as fast at doing what? I support that it's only half as fast as a sheevaplug *compiling code*. But of course the pi has a FPU, GPU, ...
Re: [9fans] c++
On Thu, Nov 22, 2012 at 09:54:34AM +, Balwinder S Dheeman wrote: > On 11/20/2012 03:42 PM, Steve Simon wrote: > >>How do you studiously not do something? Doesn't the imply working > >>hard at something? > > > >Indeed, everything I did read about Go made it look very attractive so I am > >ignoring it > >as I know myself. If I read more I will start to get annoyed that I am > >wasting my time learning C++ > >when Go is a much better solution. Its the sam reason I use plan9 and not > >Windows/Linux/OSX etc. > > > >its a backhanded compliment to the Go authors that I must not look at their > >work (yet). > > Me, OTOH, would like see Go go out of fashion ASAP; What's so > special a C/C++ programmer can't do what she/he can do with Go? I find big wins in go, but I hope it will be still improved. The lack of header files is very nice, to mention only one big annoyance I see in C/C++. :) C/C++ don't have so fast (and ready) 'goroutines'. I hate writing state machines; let the per-goroutine-stack hold every state!
Re: [9fans] apparently nice summary of small linux pcs
On Mon, Jul 16, 2012 at 08:44:52AM +, opryy...@gmail.com wrote: > Another neat comparison of 44 tiny devices: > http://dl.dropbox.com/u/4035896/a320_downloads/SBC_comparison44.pdf I think this one looks very good too in terms of price/features, advised by some colleagues: http://www.fanlesstech.com/2012/07/minix-tv-box-h24.html http://dx.com/p/h24-mini-android-4-1-network-media-player-w-wi-fi-hdmi-usb-tf-av-blue-4gb-143241 > On Sunday, 17 June 2012 18:20:35 UTC+1, (unknown) wrote: > > http://raymii.org/cms/p_Small_Linux_PCs_overview > > > > Arnold >
Re: [9fans] Mini PCs
On Tue, Jun 12, 2012 at 06:48:22AM -0700, David Leimbach wrote: > On Tuesday, June 12, 2012, Lluís Batlle i Rossell wrote: > > I'm very happy with my Sheevaplug. It works with heavy cpu loads (full gnu > > system builds from time to time) for days, and works very good. It's > > serving me > > very well already three years I think. > > > I have a guruplug I've got very little time for, but getting Plan 9 on it > was no problem. I don't do anything with heavy CPU or network usage on > Plan 9 anyway. I'm a bit surprised at the thermal problems, and I believe > there was a promise to address them, but I lost interest. For what I know, they took back the first guruplugs, that got burnt soon. Then they fixed them adding a fan. And globalscale now advertises the DreamPlugs as "without internal moving parts", in contrast to the fan they had to add to the guruplug.
Re: [9fans] Mini PCs
On Tue, Jun 12, 2012 at 01:12:55AM -0400, Kurt H Maier wrote: > Evaluations of the Sheevaplug in particular revealed it tended to > overheat badly if you put any significant load on the networking > components. Heating problems combined with poor quality control would > be my guess as to why that whole thing never flew. > I'm very happy with my Sheevaplug. It works with heavy cpu loads (full gnu system builds from time to time) for days, and works very good. It's serving me very well already three years I think. I've it connected to a 100Mbps switch though, no gigabit. I've replaced capacitors in its power supply twice, though - they blew up. I think the power supply is not very well designed, but those big capacitors are cheap. Regards, Lluís.
Re: [9fans] Sad News
On Thu, Oct 13, 2011 at 07:19:59PM +0200, tlaro...@polynum.com wrote: > And it's a chance that there is no Nobel for mathematics or computer > science: no need to be deshonored by this mondaine crap. Or there are shameful "Nobel" prizes, like the economics, started by the Bank of Sweden taking profit of Nobel's name, and with very strong political biases, denounced even by those receiving the award. And presented by the press usually neglecting these details.
Re: [9fans] NIX 64-bit kernel is available
On Wed, Sep 14, 2011 at 04:38:42PM -0400, s s wrote: > Very nice. > > Are you sure you want to call it NIX, though? > > A google search for "nix kernel" returns a lot of unrelated results. > > http://www.google.com/#hl=en&q=nix+kernel As google results depend on who searches... I "work" for a project under the name of nix for some years: http://nixos.org/nix/ As for one example. Bye, Lluis.
Re: [9fans] Ken Thompson page
On Wed, Jul 27, 2011 at 10:49:03AM -0300, Iruatã Souza wrote: > works for me. Right. Now it works for me too. > 2011/7/27 Lluís Batlle i Rossell : > > http://cm.bell-labs.com/who/ken/trust.html > > errstr: '/usr/web/who/ken' does not exist
[9fans] Ken Thompson page
Hello, I just wanted the article about security and the self-referencing compiler from Ken. http://cm.bell-labs.com/who/ken/trust.html errstr: '/usr/web/who/ken' does not exist And the Wayback Machine from archive.org does not have it due to robots.txt Is this normal and expected by the site owners? Thank you, Lluís
Re: [9fans] localization
On Wed, Apr 27, 2011 at 02:17:54PM -0400, erik quanstrom wrote: > > Those knowing how to program well are those who can deal with English > > easily. > > Writing with a latin script without diacritics makes the life easier too. > > Even > > the whole old story about 'char' holds a character can go just fine. > > > > It's also easier to deal with fixed-width fonts than with many typing > > fanciness, > > as it is easier to take types as fixed drawings than combine them as in > > arabic. > > both of these problems are quite easy to solve, since they > can be solved once, and are solved problems in plan 9. But then comes the antialiasing, the subpixel rendering for LCDs, the hinting, and all becomes quite complex. I think plan9 works mostly with bitmap fonts, isn't it? I was not aware that plan9 had the arabic linking solved. Good to know! As for the localisation of software, regarding the implementation to allow comfortable localisation without much trade-offs, I can't suggest anything of value now. Thank you, Lluís.
Re: [9fans] localization
On Wed, Apr 27, 2011 at 07:08:27PM +0200, Gabriel Diaz wrote: > Hello > > We install operating systems in English. Spanish / Catalan localized > systems are a source of problems like: > ... Hello, I think it's easier to find a programmer that wants to fix a program behaviour, than to find someone willing to do or fix a translation. And in the world of open source, most of the programming efforts go towards getting the programs do de job, and then create or fix something else. Those knowing how to program well are those who can deal with English easily. Writing with a latin script without diacritics makes the life easier too. Even the whole old story about 'char' holds a character can go just fine. It's also easier to deal with fixed-width fonts than with many typing fanciness, as it is easier to take types as fixed drawings than combine them as in arabic. I think programmers will often have an opinion biased towards their skills (knowing English) and their interests (making programs work and then fix the next). I particularly enjoy good translations into my language, both in programs, books, films, or whatever. I find it, translating, a job to be proud of. > On Wed, Apr 27, 2011 at 6:14 PM, erik quanstrom wrote: > > !/bin/upas/marshal -s 'Re: [9fans] localization' -R /mail/fs/mbox/3100 > > 9fans@9fans.net > > On Wed Apr 27 12:04:56 EDT 2011, dexen.devr...@gmail.com wrote: > >> browsing through uriel's slides from fosdem 2006 [1], i see him mention > >> Plan 9 > >> lacks localization. what are this lists feelings on localization (both > >> translation of strings and formatting of numbers, time etc.) of user-facing > >> applications? > > > > it's not the implementation that bothers me so much as the > > theory of operation. command-line utilities are localized s.t. > > it becomes necessary to fiddle with the locale if you want to > > parse the output. but then you can't present this as localized > > output yourself easily. localization can go as far as changing the set > > of digits, or even the default numbering base! they also don't > > choose a character set. shell scripting becomes impossible. > > > > i realize no localization makes life difficult for folks who speak greek. > > it would be interesting to hear from a non-native english speaker > > on if they think dealing with the computer in english is something > > that can be done once and then forgotten, and if this is less work > > than dealing with the tower of locale. > > > > it would be interesting to hear ideas on this. it's a hard problem. > > > > - erik > > > > >
Re: [9fans] sheevaplug catatonic
On Sat, Jan 15, 2011 at 03:09:50PM -0500, erik quanstrom wrote: > has anyone else had a sheevaplug go catatonic? > mine reset yesterday and now no longer responds > to the usb/serial interface and the ethernet lights > are stuck. After one year of working, in mine some power supply capacitors blew up. I replaced them, and it worked again. After two months, more old capacitors of the power supply blew up. When I had all replaced, it worked again, and I've not had any problem since then. It even stays less warm than before. Regards, Lluís.
Re: [9fans] sheevaplug catatonic
On Sun, Jan 16, 2011 at 02:41:57PM -0500, erik quanstrom wrote: > i haven't cracked the case. does anyone know if there's > a jtag port at all in a sheevaplug? There is. I've used it to debug Linux boots with openocd. The FTDI chip at the the USB-device connector should show you two serial ports. One for the console, and the other for the JTAG.
Re: [9fans] off the air
On Fri, Dec 31, 2010 at 01:28:17PM +, Richard Miller wrote: > > Although I'd like to try a theremin one day... > > Lydia Kavina http://www.lydiakavina.com gives occasional tutorials in Oxford, > maybe also somewhere closer to you. She was in Lippstadt last November. Thank you! I did not know her. I always preferred the name 'Termenvox' though. I think it was the BBC that sent a good documentary about the history of Lev Termen and his invention.
Re: [9fans] kirkwood (sheevaplug) configuration changes
Hello, On Wed, Apr 14, 2010 at 04:58:29PM -0400, ge...@plan9.bell-labs.com wrote: > There's been no significant progress on usb, flash access nor > write-back l2 cache, despite several of us banging our heads > against usb and cache walls. > >From what I could follow (little) from the linux-arm list, there may be hw problems with that l2 cache. Here you have the thread: http://lists.arm.linux.org.uk/lurker/message/20091206.141601.bde66128.en.html
