Re: [9fans] Plan 9 5th Edition

[James A. Robinson]

9fans - best served dry.

Re: [9fans] Plan 9 5th Edition

[Kurt H Maier]

On Sat, Nov 19, 2016 at 10:26:36PM -0600, Ryan Gonzalez wrote:
> ...which got shut down earlier this year:
> 
> https://opensource.googleblog.com/2015/03/farewell-to-google-code.html?m=1
> 

This must have come to a shock to their users!  I wonder what they did

Re: [9fans] Plan 9 5th Edition

[Ryan Gonzalez]

...which got shut down earlier this year:

https://opensource.googleblog.com/2015/03/farewell-to-google-code.html?m=1

--
Ryan (ライアン)
Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else
http://kirbyfan64.github.io/

On Nov 19, 2016 8:41 PM, "hiro" <23h...@gmail.com> wrote:

> i have heard good things about google code
>
>

Re: [9fans] Plan 9 5th Edition

[hiro]

i have heard good things about google code

Re: [9fans] Plan 9 5th Edition

[Stanley Lieber]

http://fqa.9front.org/fqa0.html#0.2.3

sl

Re: [9fans] Plan 9 5th Edition

[David Arnold]

On 17 Nov 2016, at 12:18, Kurt H Maier wrote:
> On Wed, Nov 16, 2016 at 07:55:38PM -0500, Charlie Lin wrote:

>> Also does anyone want to host the source tree in a repository?
>
> This sounds like a lot of work.  Who would undertake this??

GitHub, GitLab, or BitBucket all provide gratis repository hosting for Git 
and/or Mercurial.  If one of those were adopted, the work involved for ongoing 
maintenance is minimal.




d

signature.asc
Description: OpenPGP digital signature

Re: [9fans] Plan 9 5th Edition

[Steve Simon]

Almost all of the original plan9 team work for google now.

some of them work on Go, a language which has shared ancestry with alef and 
limbo.

there are not maintainers as such, though some people do maintenance and some 
still develop new features and ports.

plan9 is ad hoc.

i still think it's vastly better than anything else.

and what i want for plan9?
native gcc cross compilers (for work), oauth2 support in webfs, native firefox, 
and native svn would do nicely.

-Steve

> On 19 Nov 2016, at 20:37, Charlie Lin  wrote:
> 
> Any features that should be incorporated into Plan 9?
> Also, where are the developers? Do they still maintain it? If not, I guess we 
> assume the role of maintainers...
> 
> 
>> On Nov 16, 2016 17:27, "Charlie Lin"  wrote:
>> Any plans for Plan 9 5th edition?
>> 
>> My desires:
>> ISO-compliant C compiler and preprocessor
>> Port other programming languages (especially Go) to here
>> Start a source code repository
>> Port Git, SVN, Mercurial, et cetera to here

Re: [9fans] Plan 9 5th Edition

[Charlie Lin]

Any features that should be incorporated into Plan 9?
Also, where are the developers? Do they still maintain it? If not, I guess
we assume the role of maintainers...

On Nov 16, 2016 17:27, "Charlie Lin"  wrote:

> Any plans for Plan 9 5th edition?
>
> My desires:
> ISO-compliant C compiler and preprocessor
> Port other programming languages (especially Go) to here
> Start a source code repository
> Port Git, SVN, Mercurial, et cetera to here
>

Re: [9fans] Plan 9 5th Edition

[Charlie Lin]

Add one more: XHCI (USB 3.0) support, because the USB device driver
currently does not support it, as stated in the USB man page in section 3

On Nov 16, 2016 17:27, "Charlie Lin"  wrote:

> Any plans for Plan 9 5th edition?
>
> My desires:
> ISO-compliant C compiler and preprocessor
> Port other programming languages (especially Go) to here
> Start a source code repository
> Port Git, SVN, Mercurial, et cetera to here
>

Re: [9fans] Plan 9 5th Edition

[Steve Simon]

Cinap,

I salute you and the good sense you write.

-Steve




> On 19 Nov 2016, at 16:57, cinap_len...@felloff.net wrote:
> 
> calling into firmware code is a big can of worms because firmware is full
> of bugs and only works with a small set of the major operating systems that
> the firmware authors tested it with.
> 
> and theres not really an option for doing it from userspace.
> 
> you need to call it from kernel mode ring zero and make sure the firmware
> has the same idea of the virtual memory mappings as your kernel plus
> work arround the unstated assumptions of the firmware.
> 
> linux has a track record of bricked machines and firmware corrupting
> memory.
> 
> it is just not worth it.
> 
> in 9front, the kernel never calls firmware. it does interpret a limited
> set of acpi methods on boot to figure out pci interrupt mappings and
> and then frees the acpi environment never to return.
> 
> all efi/bios calls are done by the bootloader *before* it enters the kernel
> so we never have to rely on efi/bios firmware assumptoins. the bootloader
> collects the information from efi and passes it to the kernel as plan9.ini
> variables.
> 
> efi firmware has a boot manager were the user can add and modify entries.
> 
> --
> cinap

Re: [9fans] Plan 9 5th Edition

[cinap_lenrek]

calling into firmware code is a big can of worms because firmware is full
of bugs and only works with a small set of the major operating systems that
the firmware authors tested it with.

and theres not really an option for doing it from userspace.

you need to call it from kernel mode ring zero and make sure the firmware
has the same idea of the virtual memory mappings as your kernel plus
work arround the unstated assumptions of the firmware.

linux has a track record of bricked machines and firmware corrupting
memory.

it is just not worth it.

in 9front, the kernel never calls firmware. it does interpret a limited
set of acpi methods on boot to figure out pci interrupt mappings and
and then frees the acpi environment never to return.

all efi/bios calls are done by the bootloader *before* it enters the kernel
so we never have to rely on efi/bios firmware assumptoins. the bootloader
collects the information from efi and passes it to the kernel as plan9.ini
variables.

efi firmware has a boot manager were the user can add and modify entries.

--
cinap