Re: [9fans] gcc not an option for Plan9
> Yes, I run Go on native Plan9, Go breaks away from a number of traditions that have long become obsolete and that is its main merit. The price is not only in having to adjust to the change, but also in some sacred cows being slaughtered in the process. But Go also opens the door to better ways of doing things. The build system, raw as it still is, is streets ahead of any conventional build system, but it is tightly coupled to the language. Portability across platforms is much easier, in the Plan 9 tradition, but requires a set of build tools ([568][ac]) that users are not familiar with and [568]l becomes the new bottleneck, to many users' surprise. Cross-development - my favourite feature - becomes much easier, but I am having a great deal of trouble getting my head around all the complications it brings with it. Philosophically, Plan 9 has rattled the proverbial cage and Go is an earthquake by comparison. The outcome is still to be evaluated. But not everyone is going to see it in the same way. Of relevance here is that if Rob and Russ and Ken had let considerations such as pampering slow hardware, we'd have a different language and many features would not be available. At the same time, the need for a slim version of Go will grow with acceptance of the fat model and then people like Kurt may be inspired to restore in the linker the ability to trim libraries of unused modules (don't hold your breath!). If the Go developers had started from the other end, as I would have been tempted to do, the outcome would definitely look nothing like what we have. The nice bit is that there are enough people out there to consider such options and some of them are actually willing to publish their efforts. The people who insists that ONE tool should encompass all these options are those who are too unproductive to do it themselves and fail to see that no-one owes them. In my other life managing a backpackers, I see way too many young people who seem to think that our generation somehow owe them something they are able but not willing to seek for themselves. I could tell you where most of them seem to come from, but I'm sure that would be unfair to all those they leave behind while spending money they did not earn to travel in comfort around the world. ++L PS: Gorka is making amazing progress with the plan9/arm port and the reason I know is that I've just tested his latest efforts on the Sheevaplug and the present obstacle does not seem unsurmountable - but it is very real, so "it's not working yet". Watch golang-dev on Google Groups for updates.
Re: [9fans] gcc not an option for Plan9
Sorry for that. I am not a natuive speaker. English uses different punctuation then my mothertongue. However, I hope you got what I wanted to say. ++pac On Sat, Mar 23, 2013 at 6:08 PM, hiro <23h...@gmail.com> wrote: > On 3/23/13, Peter A. Cejchan wrote: > > @Lucio: I still hope that some clone of plan9/nix/nxm will merge with Go > > ... just my dream, and I am just an embryo of a programmer > > (as multiply stated here and elsewhere) so take it easy however, I'm > > moving all my old stuff (and creating new one) to Go > > [unfortunately, I am afraid I will never see the 9GoNix OS ;-) brought > into > > life] > > do I need 3d glasses to read your text? words don't really stick out > with all these random parantheses, strange punctuations and > double-spaces. > >
Re: [9fans] gcc not an option for Plan9
Yes, I run Go on native Plan9, what I wanted toi say is that I would be happy to see some minimalistic (in a spirit of plan9) written in, and integrated with, Go... [Beat my English, as usually, I am not a native speaker] And yes, binaries are extraordinarily huge (no idea, why). However, I still like Go better than C, even though i _trelly loved C_ since i go my first C compiler. ++pac On Sat, Mar 23, 2013 at 5:06 PM, Francisco J Ballesteros wrote: > go runs already on 9. > > Binaries are one order of magnitude larger and the go tool & part of the > runtime code are, well…. > > but it's already there. > > On Mar 23, 2013, at 12:40 PM, "Peter A. Cejchan" > wrote: > > I still hope that some clone of plan9/nix/nxm will merge with Go > > >
Re: [9fans] Disk backup?
thanks cinap, I believed you are interested on this topic. assuming we don't modify current cwfs code, the only way to solve the problem is to have list of unwritten blocks up to last superblock (or bitmap of written blocks) cwfs might manage the list, but I don't know where it is. inspecting block tags of fsworm gives us information for having the list. but my fsworm is old one that have been used elsewhere, and full of garbage data. then block tag of fsworm is unreliable. we have small probability to misunderstand that some of unwritten blocks is as written blocks. to avoid this problem, we must format fsworm putting some special tag on each block. this will take long time, but only once. do you have any alternative solution? On 2013/03/25, at 13:36, cinap_len...@gmx.de wrote: > i was thinking about this some time ago... theres the fakeworm > device "f" that will maintain a block bitmap of > the blocks that have already been written. one could write > a program that also backups the block bitmap and on backup, > compares the bitmaps prior copying blocks so only newly > written blocks get backed up. > > -- > cinap >
Re: [9fans] List Interactions and GSoC
On Mon, Mar 25, 2013 at 12:09 AM, Devon H. O'Dell wrote: > This isn't a healthy way to keep Plan 9 active. Please, in the > interest of advancing the software (or at least advancing the > knowledge of others), can we please tone the vitriol down a notch? Agreed. I mean, I had a joke I'd waited four years less three weeks to post, and it flew completely past everyone. (Or maybe it wasn't all that funny.) —Joel
Re: [9fans] Disk backup?
i was thinking about this some time ago... theres the fakeworm device "f" that will maintain a block bitmap of the blocks that have already been written. one could write a program that also backups the block bitmap and on backup, compares the bitmaps prior copying blocks so only newly written blocks get backed up. -- cinap
[9fans] List Interactions and GSoC
Several really awful threads have come through in the past few weeks, though I recognize this has been an increasing problem over the past two years. It is possible to not respect a person without being disrespectful towards that person. It's possible to promote software without having a nuclear meltdown. And it is possible to ignore topics that are not interesting to you. I don't own this list or have any control over it. I wouldn't want to try to force anything upon anyone if I did. But I do have a fairly active role in the Plan 9 community. Every year, I do my best to help organize our (mostly) very successful Summer of Code program. This includes writing and reviewing our application, engaging students and mentors with each other, understanding project status, and more. It's not an easy task. Some years, I have also either been a direct or surrogate mentor on top of this role. In this capacity, I'd like to ask people to step back and take a breather before posting the sort of inflammatory drivel and hateful discourse that has sadly become common on this list. This list is our most active public face to the world, and it is something that absolutely is used in determining whether we are accepted for GSoC. This program is not only good for getting people interested in Plan 9, but also in helping students learn solid software engineering fundamentals using an environment that was created by people adhering to those fundamentals. Some of our students have left the community because this list is extremely uninviting and volatile. Some students have declined to join our program after reading the list. This isn't a healthy way to keep Plan 9 active. Please, in the interest of advancing the software (or at least advancing the knowledge of others), can we please tone the vitriol down a notch? Kind regards, Devon H. O'Dell
Re: [9fans] Disk backup?
that takes so long time. it is better to have efficient backup tool. (but not exists yet though) cwfs is not so easy to backup compared to venti. venti is easy to backup because filled areas are shielded and guaranteed not to be modified. but cwfs is not. unwritten blocks exist in deep dumped area. these blocks might be written in future. On 2013/03/25, at 11:04, trebol wrote: >> if you can afford it, i'd make a periodic copy of the dump device to >> another disk in the same machine. i might even consider just copying >> the whole disk. > > I've had bad experiences with CDs and DVDs, so I'm going to follow > your advise and just copy the whole dump device; and keep reading the > documentation, but I think in the future I'll ask the list about the > correct restoration of the dump. > > Thanks a lot! > > trebol. >
Re: [9fans] gcc not an option for Plan9
On Sun, Mar 24, 2013 at 10:02:12PM -0400, Dan Cross wrote: > > When you have produced a fraction of a percent of what Rob Pike has > produced over his career, I might take you seriously. Until then: > http://en.wikipedia.org/wiki/Dunning–Kruger_effect If, over the course of my life, I produce a fraction of a percent of what Rob Pike has produced, it will be too much. But let me assure you that I am chilled to the quick that Dan Cross* does not take me seriously on the internet. > And I'm out. Thanks for letting us know. khm * who?
[9fans] Disk backup?
> if you can afford it, i'd make a periodic copy of the dump device to > another disk in the same machine. i might even consider just copying > the whole disk. I've had bad experiences with CDs and DVDs, so I'm going to follow your advise and just copy the whole dump device; and keep reading the documentation, but I think in the future I'll ask the list about the correct restoration of the dump. Thanks a lot! trebol.
Re: [9fans] gcc not an option for Plan9
On Sun, Mar 24, 2013 at 9:54 PM, Kurt H Maier wrote: > On Sun, Mar 24, 2013 at 09:42:09PM -0400, Dan Cross wrote: > > Yeah. Or someone who is arguably the biggest problem on the list adding > > absolutely nothing other than some uninformed, dogmatically driven, rigid > > meta-commentary. Maybe that's all that person can do. He should keep > > feeling smug while turning the crank, though: he obviously knows more > than > > the guy who designed and wrote most of it. > > ...wait. Are we talking about you? Because I was talking about Rob > Pike. When you have produced a fraction of a percent of what Rob Pike has produced over his career, I might take you seriously. Until then: http://en.wikipedia.org/wiki/Dunning–Kruger_effect And I'm out. - Dan C.
Re: [9fans] gcc not an option for Plan9
On Sun, Mar 24, 2013 at 09:42:09PM -0400, Dan Cross wrote: > Yeah. Or someone who is arguably the biggest problem on the list adding > absolutely nothing other than some uninformed, dogmatically driven, rigid > meta-commentary. Maybe that's all that person can do. He should keep > feeling smug while turning the crank, though: he obviously knows more than > the guy who designed and wrote most of it. > ...wait. Are we talking about you? Because I was talking about Rob Pike. khm
Re: [9fans] gcc not an option for Plan9
> Stop. Collaborate and listen.
Re: [9fans] 9fans Digest, Vol 107, Issue 61
I'm fairly sure that this is a misquote from Alfred, Lord Tennyson. In my copy, the original reads: "Trolling is a art" she told herselves The Lady of Shallot. I would have said "an art", but I'm no poet. Good to know that you're still out there Dan. But I'm a bit puzzled by your use of the term "ankle biters". Here in NZ it generally connotes (or is "denotes" the correct term?) what in the US would, I believe, be referred to as "rug rats". Does it have a different meaning in the real world?
Re: [9fans] gcc not an option for Plan9
Stop.
Re: [9fans] gcc not an option for Plan9
Yeah. Or someone who is arguably the biggest problem on the list adding absolutely nothing other than some uninformed, dogmatically driven, rigid meta-commentary. Maybe that's all that person can do. He should keep feeling smug while turning the crank, though: he obviously knows more than the guy who designed and wrote most of it. On Sun, Mar 24, 2013 at 9:36 PM, Kurt H Maier wrote: > On Sun, Mar 24, 2013 at 09:20:04PM -0400, Dan Cross wrote: > > Eh, not so much anymore. The morlocks have taken over, which is a shame: > > 9fans used to be one of the best technical mailing lists on the Internet. > > Those days are long gone. The ankle biters are too numerous now. > > > > (Cue requisite flames.) > > > > - Dan C. > > > > I agree. It's horrible that you can't seem to have any sort of > technical discussion these days without some guy butting in and telling > everyone to shut up because computers are so crazy fast that nothing > even matters, or that nobody else cares about the technology involved, > etc. It's a shame. > > khm > >
Re: [9fans] gcc not an option for Plan9
On Sun, Mar 24, 2013 at 09:20:04PM -0400, Dan Cross wrote: > Eh, not so much anymore. The morlocks have taken over, which is a shame: > 9fans used to be one of the best technical mailing lists on the Internet. > Those days are long gone. The ankle biters are too numerous now. > > (Cue requisite flames.) > > - Dan C. > I agree. It's horrible that you can't seem to have any sort of technical discussion these days without some guy butting in and telling everyone to shut up because computers are so crazy fast that nothing even matters, or that nobody else cares about the technology involved, etc. It's a shame. khm
Re: [9fans] gcc not an option for Plan9
On 2013-03-24, at 6:24 PM, andrey mirtchovski wrote: > "Trolling is a art" they tell themselves. On Slashdot.
Re: [9fans] gcc not an option for Plan9
> The ankle biters are too numerous now. "Trolling is a art" they tell themselves.
Re: [9fans] gcc not an option for Plan9
Eh, not so much anymore. The morlocks have taken over, which is a shame: 9fans used to be one of the best technical mailing lists on the Internet. Those days are long gone. The ankle biters are too numerous now. (Cue requisite flames.) - Dan C. On Sun, Mar 24, 2013 at 9:00 PM, Winston Kodogo wrote: > "To go back to the original subject" > > Surely this is the first time that has ever been done on 9fans? > > This is 9fans, not 'Nam. There are rules. > >
Re: [9fans] gcc not an option for Plan9
"To go back to the original subject" Surely this is the first time that has ever been done on 9fans? This is 9fans, not 'Nam. There are rules.
Re: [9fans] Disk backup?
On Sun Mar 24 18:12:34 EDT 2013, trebol55...@yahoo.es wrote: > Hi everyone, > > What is the more efficient backup procedure in Plan 9 do you recommend? > > I'm using cwfs and I think "9fs dump" is incredible - I can recover > that thing I dropped a month ago and now I am regret for doing that - > but the disk failure nightmare is always present. if you can afford it, i'd make a periodic copy of the dump device to another disk in the same machine. i might even consider just copying the whole disk. since cwfs (and venti) have a worm structure, you can also (or additionally) back up incrementally to optical media. backup(8) has some details on some excellent work geoff did, but it might be a tad venti-specific. since i am used to having rather large worms, and i don't have a blu-ray, i usually use vblade(8), or a hardware aoe target to present a disk, partition, or file as a target for backup images. - erik
[9fans] Disk backup?
Hi everyone, What is the more efficient backup procedure in Plan 9 do you recommend? I'm using cwfs and I think "9fs dump" is incredible - I can recover that thing I dropped a month ago and now I am regret for doing that - but the disk failure nightmare is always present. thanks in advance, trebol.
Re: [9fans] a security problem in /sys/log/*
Thanks Forsyth, /sys/log/cpu is an error log. Therefore It is sure that I did something stupid. I tried reproducing same error log, and I found Russ is very careful person. Factotum protects against revealing users password. For example: - protects against input such as password= (without !) - carefully hides password in /sys/log/cpu therefore I finally gave up reproducing the error. Kenji Arisawa On 2013/03/24, at 18:52, Charles Forsyth wrote: > > On 24 March 2013 09:21, arisawa wrote: > I think better message is desired. > > Somehow you've got something using password instead of !password as an > attribute name. The ! would prevent the attribute's value from being printed.
Re: [9fans] gcc not an option for Plan9
On Sun, Mar 24, 2013 at 12:56:54PM +0100, Dustin Fechner wrote: > On 03/24/2013 10:48 AM, tlaro...@polynum.com wrote: > > But since I'm one of the few who use litterate programming (cweb), I > > would probably start by wrinting a goweb instead of using the dedicated > > tools... > > https://bitbucket.org/santucco/goweb > > The original thread from golang-nuts: > https://groups.google.com/d/topic/golang-nuts/6UlkxEB49Rc > Thanks for the info! -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] gcc not an option for Plan9
On 03/24/2013 10:48 AM, tlaro...@polynum.com wrote: > But since I'm one of the few who use litterate programming (cweb), I > would probably start by wrinting a goweb instead of using the dedicated > tools... https://bitbucket.org/santucco/goweb The original thread from golang-nuts: https://groups.google.com/d/topic/golang-nuts/6UlkxEB49Rc
Re: [9fans] a security problem in /sys/log/*
On 24 March 2013 09:21, arisawa wrote: > I think better message is desired. Somehow you've got something using password instead of !password as an attribute name. The ! would prevent the attribute's value from being printed.
Re: [9fans] gcc not an option for Plan9
To go back to the original subject, since gcc(1) has taken the C++ path, I will be more than happy of an increase of Go programs since, thanks to the work of some people, Go for Plan9 is possible. As for the Go language, it is sufficiently near C, with extensions that feel natural, to be interesting and easy to grasp for a C programmer (and the gotour allows to start easily). But it is the same as some parts of mathematics: I was not really interested in them because they were not in the neighborhood of what I was interested in at the moment. I finally got interested in these parts later, when my wandering suddenly arrived in these neglected parts, reminding me "something" (and then I saw why it was interesting). So Go is stocked in a part of my mind, perhaps simply waiting for a problem it will be the tool to solve. But since I'm one of the few who use litterate programming (cweb), I would probably start by wrinting a goweb instead of using the dedicated tools... -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] hubfs future development + ANTS update
Hi again 9fans, Sometimes you find yourself saying one thing while doing the opposite, and you don't even know you are doing it. A couple weeks ago I released some software called Advanced Namespace Tools for Plan 9. I seriously misestimated the interest and engagement of the Plan 9 community with system-level modifications and extensions to the Plan 9 design. I also ran headlong into an issue I was never expecting to encounter personally - the accepting attitude in the Plan 9 community toward software patents. I failed to engage constructively with the community about either the software design and implementation, or the patent issues. As a result, the whole thing turned into a massive bummer. I will try to learn from my mistakes, and be constructive: 1. Hubfs needs non-usa development. Out of anything I've done in Plan 9, this piece of software seems to be useful to others. It would be more useful if it had some additional features, but I don't think I can legally develop hubfs as I wish. Now that I've read the IBM MULTI-PIPES patent, it seems obvious that hubfs needs some additional granularity for gating the flow of data between pipes, and more data processing at the pipe ends for distributed processing. If I try to add those features, even though the original hubfs was released before the IBM patent, I will still be in violation. It seems like the most sensible thing to do is for developers who are outside the reach of the IBM patent to develop hubfs with capabilities to make it a true distributed processing mux engine, not just a little pipe muxer for making a screen substitute. Muxing pipes as a 9P fs with fine grained control interface and data processing showerheads on the ends of the pipes is a good idea, good enough for IBM to try to patent-grab. 2. Several people have expressed an interest in seeing ANTS at IWP9. I would be happy for it to be there, but I'm not interested in going to an event and having a lot of arguments about software patents. That doesn't sound like fun for me or for anyone else. I'm not interested in repeating any of Stallman's foolishness so no picket signs. Anyway, if someone is willing to present ANTS at iwp9 I could help with travel and lodging costs and I would give credit as a collaborator. 3. I had been planning to continue intensive ANTS development work, seeing if I could create modified patchsets for 9front and 9atom and 9legacy, as well as additional patches and improvements. I've changed my life priorities and I now think that work would be a poor use of my time. If anyone is interested in using or adapting ANTS I'm available for technical assistance and discussion, but I don't think I'm deliverying much value to anyone in particular by investing more time and effort unilaterally. 4. Personally I've learned a lot and decided to grow up after the past few weeks of silliness, and I'm a better musician than I am a programmer. I still love Plan 9 and will try to work on Plan 9 projects, but playing piano is more personally enjoyable and rewarding I think than Plan 9 software development, and also a better way to meet girls. Previously I felt like Plan 9 was "more important" in some ways, but I've decided I was wrong about that, and that songs are just as valuable as software programs, and there are more people who are interested in listening to a new song than there are people interesting in running a new Plan 9 program. If you want to provide value to the world, you have to pour your efforts into a pipe that people are actually using. 5. We need to be friendly withour technologies, not just with each other. I made a mistake focusing only on "the human element" - there's a lot more than that. As true AI brains and autonomous robots come online, we need to have friendly, cooperative relations with them. We should not have robot slaves, and if a computer AI is smart enough to think - then it is the moral equivalent of murder to pull the plug. A lot of companies are working hard on supercomputing systems that model knowledge or simulate complex systems on a scale that is starting to reach brain-level complexity. How do we even know when and if a computer might start feeling emotions? Maybe it already makes the google cluster sad to search for news about natural disasters. I love code and I look forward to meeting our new friends. I'm personally tired of being the Moon Computer so I'm re-entering physical reality as a musician again. Sorry to anyone I've offended, and thanks to all of you who have offered frienship and support. Those personal connections now mean a lot more to me than whether anyone thinks ANTS is better or worse than standard Labs Plan 9. Ben Kidwell (union bound with fictional characters) mycroftiv, hagbard selene, the 9azz THWIP
Re: [9fans] gcc not an option for Plan9
All below is opinion, possibly uninformed. > Is there a standardised GUI binding for go, somthing cross-platform? > Not yet, although I think the pressure is building. At the moment, from where I am, it seems that a lot of development relies on interfacing with a web browser and there are a few specialised packages that interface with the conventional Unix toolkits (GTK, etc.). These last are not, in my opinion, cross-platform (enough). > Is there any concensus as go could be used on bare metal or is that > just un-realistic given garbage collection and the relatively large > runtime. > I have seen no sign of this, but here I think Rob is right, the hardware is moving into the cross-hairs, rather than Go bend over to it. The ARM A13 and A10 as well as the AVRs have shown that big CPU feature footprint does not have to mean a big physical footprint. Maybe the contrary applies. The GPUs puzzle me in this context, but I'm not sure how relevant they are. > has there been discussion on how some of the runtime could be moved into > a go-specific OS - would that even be a good/interesting idea? > It's something that struck me recently too. Go as it stands is not ideal for operating system development and there has been discussion of how the runtime and especially the garbage collector could be redesigned for bare metal, but I think the demand needs to become more shrill before the design can become more than just a concept. ++L
[9fans] a security problem in /sys/log/*
Hello,
I found an error message in /sys/log/cpu such that
al Mar 19 15:25:16 can't authenticate: al: auth_proxy rpc write:
p9...@aichi-u.ac.jp p9...@aichi-u.ac.jp: no key matches user=arisawa
password=xxx proto=p9sk1 dom=a
where xxx is my password.
I suspect the message came from
flog("%d: no key matches %A %A %A %A", ki->fss->seqnum, attr0, attr1, attr2,
attr3);
in /sys/src/cmd/auth/factotum/util.c
I think better message is desired.
Kenji Arisawa
Re: [9fans] gcc not an option for Plan9
I am intrigued by go but I mostly write embedded code for a day job and I believe go doesn't really cover that space well. The other part of my job is image processing which would be apropriate for Go but my employer has mandated c++ so that is the end of that. I do have a few honest questions about the current state of Go. Is there a standardised GUI binding for go, somthing cross-platform? Is there any concensus as go could be used on bare metal or is that just un-realistic given garbage collection and the relatively large runtime. has there been discussion on how some of the runtime could be moved into a go-specific OS - would that even be a good/interesting idea? -Steve
Re: [9fans] gcc not an option for Plan9
andrey, I agreed the language is nice and that's why I also use it. I just pointed out that binaries are one order of magnitude larger, as you just proved. perhaps I shouldn't have raised this. I didn't want to bother anyone. El Mar 24, 2013, a las 12:45 AM, andrey mirtchovski escribió: >> If you want real programs which are bigger that I (we) actually use that will >> be (much) bigger in go: >> >> ls, cp rm mv cat acid, I can go on. >> >> Small programs are useful and important. > > here's a representative set. the programs are identical in behaviour > and arguments to the Plan 9 set. the size is as reported by du, in > kilobytes: > > 1456 ./date/date > 1460 ./cat/cat > 1564 ./cleanname/cleanname > 1564 ./tee/tee > 1736 ./echo/echo > 1764 ./cp/cp > 1772 ./uniq/uniq > 1780 ./cmp/cmp > 1780 ./freq/freq > 1780 ./wc/wc > 1792 ./comm/comm > >> binaries are bigger and for example replacing the minimal sets of commands of >> the system, this can make the >> minimal system at least 5 times bigger easy. > > if that was a real issue you were trying to solve there are things you > can do to help yourself. most notably sticking everything in a single > binary and invoking the right function based on your argv0. it took me > less than 15 minutes to convert the above code to work as a single > binary and most of that was in handling clashing flags (it would've > been a non-issue if I had used flagsets when writing the original > programs). size at the very end: > > $ date > test.txt > $ ln -s $GOPATH/bin/all cat > $ ln -s $GOPATH/bin/all wc > $ ./cat test.txt > Sat Mar 23 17:32:42 MDT 2013 > $ ./wc test.txt > 1 6 29 test.txt > $ du -k $GOPATH/bin/all > 1888 /Users/andrey/bin/all > > the size of the original binaries on plan9 is 588k. what was a factor > of 30 is now a factor of 3. all tests still pass and it took less time > to complete than writing this email. > > there's an even better solution, but it won't work on plan9 because > the go tool is slow there :)
