Google Chrome OS & NACL
286 views
Skip to first unread message
lazalong
Jul 8, 2009, 8:49:04 PM7/8/09
to Native Client Discuss
After the recent announcement of "Google Chrome OS" I wondered if it
is planned that NACL work on it ?
What will be the specs for developing applications on this OS?
is planned that NACL work on it ?
What will be the specs for developing applications on this OS?
lazalong
Jul 8, 2009, 8:53:10 PM7/8/09
to Native Client Discuss
Btw here is the link: http://googleblog.blogspot.com/2009/07/introducing-google-chrome-os.html
Brad Chen
Jul 9, 2009, 5:30:18 PM7/9/09
to native-cli...@googlegroups.com
As we indicated earlier on native-client-announce, we have an effort underway to integrate Native Client into Chrome. Google Chrome OS is just another platform that will run Chrome. This relationship aside, nothing about Chrome OS changes our strategy or plans for Native Client.
Brad Chen
Engineering Manager
Native Client
Sami
Jul 9, 2009, 6:50:57 PM7/9/09
to Native Client Discuss
Brad,
You seem to say that there is nothing in common between NaCL and
Chrome OS ?
We could have imagine that Chrome OS would be built on top of NaCL, a
kind of linux kernel compiled with the modified GCC to target NaCL. It
could benefit from all the technical services provided by NaCL
plateform...
It seems strange to reinvent the wheel, don't you think so ?
Sami
> native-client-announce<http://groups.google.com/group/native-client-announce>,
You seem to say that there is nothing in common between NaCL and
Chrome OS ?
We could have imagine that Chrome OS would be built on top of NaCL, a
kind of linux kernel compiled with the modified GCC to target NaCL. It
could benefit from all the technical services provided by NaCL
plateform...
It seems strange to reinvent the wheel, don't you think so ?
Sami
> native-client-announce<http://groups.google.com/group/native-client-announce>,
> we have an effort underway to integrate Native Client into Chrome. Google
> Chrome OS is just another platform that will run Chrome. This relationship
> aside, nothing about Chrome OS changes our strategy or plans for Native
> Client.
> Brad Chen
> Engineering Manager
> Native Client
>
> Chrome OS is just another platform that will run Chrome. This relationship
> aside, nothing about Chrome OS changes our strategy or plans for Native
> Client.
> Brad Chen
> Engineering Manager
> Native Client
>
Brad Chen
Jul 9, 2009, 6:56:25 PM7/9/09
to native-cli...@googlegroups.com
Brad
Sami Jaber
Jul 10, 2009, 3:23:16 AM7/10/09
to native-cli...@googlegroups.com
I have reread your previous msg and the blog post. At no time, it is "clearly" stated that Native Client is part of Chrome OS or that you plan to merge Chrome OS to run on top of NaCL toolbox/plugin.
The term "Native Client or NaCl" is definitively not employed in the blog and you seem to say that the two projects are distinct.
Your msg doesn't associate in the same sentence NaCl and ChromeOS. So if I misunderstood, this is probably that the things aren't clear.
And for your information, I have talked with many blogguers and journalists, nobody seem to really understand the relationships between that two key technologies
I'm sure that you will remove the doubt...
Sami
The term "Native Client or NaCl" is definitively not employed in the blog and you seem to say that the two projects are distinct.
Your msg doesn't associate in the same sentence NaCl and ChromeOS. So if I misunderstood, this is probably that the things aren't clear.
And for your information, I have talked with many blogguers and journalists, nobody seem to really understand the relationships between that two key technologies
I'm sure that you will remove the doubt...
Sami
Daniel Monteiro
Jul 10, 2009, 7:35:29 AM7/10/09
to native-cli...@googlegroups.com
Its me or most people simply have forgot about NaCl? We only have blog posts and news about when it was released and when the security challenge was issued, and thats it. Too bad...
--
Daniel Monteiro
========================================
|_|0|_| Linux Registered User #424188
|_|_|0| http://batterypoweredgames.blogspot.com/
|0|0|0| Visit to grab games for your mobile device!
========================================
2009/7/10 Sami Jaber <sami....@gmail.com>
--
Daniel Monteiro
========================================
|_|0|_| Linux Registered User #424188
|_|_|0| http://batterypoweredgames.blogspot.com/
|0|0|0| Visit to grab games for your mobile device!
========================================
centipede
Jul 10, 2009, 8:43:09 AM7/10/09
to Native Client Discuss
On Jul 10, 1:35 pm, Daniel Monteiro <monteiroqu...@gmail.com> wrote:
> Its me or most people simply have forgot about NaCl? We only have blog posts
> and news about when it was released and when the security challenge was
> issued, and thats it. Too bad...
I'm still waiting with high expectations for the time when NaCl is
released per default inside the major free browsers. Heck, I even made
a small "guess-the-word" latin-practicing game just waiting in my
drawer. It was both easy and fun, and I'm eagerly anticipating more to
come.
But the picture is a bit muddy right now as to what direction things
will take, and I get the feeling that the good gentlemen at Google
face the same questions as the rest of us: What API should NaCl
provide?
I believe very much in porting large open source projects to NaCl,
coinciding with a move towards a more fullblown NaCl API providing
both (managed) file access, sockets and OpenGL thus minimizing the
difference between traditional desktop applications and webbrowser
plugins.
But that will take time like all good things. Which is quite okay.
Kind regards (and cheers to the busy NaCl team),
Rene
> 2009/7/10 Sami Jaber <sami.ja...@gmail.com>
>
>
>
> > I have reread your previous msg and the blog post. At no time, it is
> > "clearly" stated that Native Client is part of Chrome OS or that you plan to
> > merge Chrome OS to run on top of NaCL toolbox/plugin.
> > The term "Native Client or NaCl" is definitively not employed in the blog
> > and you seem to say that the two projects are distinct.
> > Your msg doesn't associate in the same sentence NaCl and ChromeOS. So if I
> > misunderstood, this is probably that the things aren't clear.
> > And for your information, I have talked with many blogguers and
> > journalists, nobody seem to really understand the relationships between that
> > two key technologies
> > I'm sure that you will remove the doubt...
>
> > Sami
>
>
>
> > I have reread your previous msg and the blog post. At no time, it is
> > "clearly" stated that Native Client is part of Chrome OS or that you plan to
> > merge Chrome OS to run on top of NaCL toolbox/plugin.
> > The term "Native Client or NaCl" is definitively not employed in the blog
> > and you seem to say that the two projects are distinct.
> > Your msg doesn't associate in the same sentence NaCl and ChromeOS. So if I
> > misunderstood, this is probably that the things aren't clear.
> > And for your information, I have talked with many blogguers and
> > journalists, nobody seem to really understand the relationships between that
> > two key technologies
> > I'm sure that you will remove the doubt...
>
> > Sami
>
> > On Fri, Jul 10, 2009 at 12:56 AM, Brad Chen <bradc...@google.com> wrote:
>
> >> Suggestion: Reread the Google blog post on Chrome OS and my previous
> >> messages, then let me know if things aren't clearer. You may have
> >> misunderstood some of what we've written previously.
> >> Brad
>
>
> >> Suggestion: Reread the Google blog post on Chrome OS and my previous
> >> messages, then let me know if things aren't clearer. You may have
> >> misunderstood some of what we've written previously.
> >> Brad
>
Ian Lawrence
Jul 10, 2009, 7:43:56 AM7/10/09
to native-cli...@googlegroups.com
Hi
> Its me or most people simply have forgot about NaCl? We only have blog posts
> and news about when it was released and when the security challenge was
> issued, and thats it. Too bad...
> Its me or most people simply have forgot about NaCl? We only have blog posts
> and news about when it was released and when the security challenge was
> issued, and thats it. Too bad...
and all the code commits
http://code.google.com/p/nativeclient/source/list
documentation updates and wiki changes as well.
Ian
--
Brad Chen
Jul 10, 2009, 9:44:29 AM7/10/09
to native-cli...@googlegroups.com
I apologize that I can't answer your questions more directly in this forum. I think Google Chrome OS is a great project, but as I don't manage it would be out of place for me to speak on their behalf. And I'd rather not restate what they have said.
What I think I can do is state explicitly what seems clear to me, from my somewhat unusual perspective. Looking forward, I like to think of operating systems as providing three basic functions:
- hardware abstraction
- resource management
- application environment
Of these three functions, Native Client focuses squarely on the application environment. One of the things I like about the project is that we don't have to muck around with device drivers and such. I'm perfectly happy letting existing operating systems, or eventually Google Chrome OS, take care of the hardware abstraction function.
The third function, resource management, is a bit special. Looking back it seems like an OS function, but if you look forward and embrace a model where client hardware is cheap and interchangeable, and where resources live in the cloud, then that assumption falls apart. If resource abstractions are distributed, perhaps they need to be managed by something like a browser.
Brad
Daniel Monteiro
Jul 10, 2009, 10:22:15 AM7/10/09
to native-cli...@googlegroups.com
To me, NaCl has the power to bring full potential to Chrome OS. And its probably the biggest tools to address its shortcommings (from what we know right now).
One thing I feel that is keeping me away from NaCl (as I have more priorities with my Linux Mobile development) is its weird build system. IMHO, this is something that should be improved ASAP.
cheers to the team. This project has the potential to change the way we both use the web and use applications today.
[]s
One thing I feel that is keeping me away from NaCl (as I have more priorities with my Linux Mobile development) is its weird build system. IMHO, this is something that should be improved ASAP.
cheers to the team. This project has the potential to change the way we both use the web and use applications today.
[]s
2009/7/10 Brad Chen <brad...@google.com>
Brad Chen
Jul 10, 2009, 10:26:28 AM7/10/09
to native-cli...@googlegroups.com
Daniel -
Thanks for the feedback. Personally I don't know of any build systems I like. We need something very portable and maintainable. What kind of build system would you suggest?
Brad
Daniel Monteiro
Jul 10, 2009, 4:56:19 PM7/10/09
to native-cli...@googlegroups.com
as much as it is also PITA, GNU make is quite portable and standard...
with the scons, I feel quite lost, as I know nothing about python and dont know where to look for help.
with the scons, I feel quite lost, as I know nothing about python and dont know where to look for help.
2009/7/10 Brad Chen <brad...@google.com>
Bennet Yee (余仕斌)
Jul 10, 2009, 5:27:04 PM7/10/09
to native-cli...@googlegroups.com
+1 and i already knew python when i was introduced to scons. :-{
but you get used to it -- i've been doing what i call cargo cult
programming for the scons stuff, and it seems to work. mostly.
-bsy
--
bennet s yee
i usually don't capitalize due to mild tendonitis
but you get used to it -- i've been doing what i call cargo cult
programming for the scons stuff, and it seems to work. mostly.
-bsy
bennet s yee
i usually don't capitalize due to mild tendonitis
Robert Muth
Jul 10, 2009, 5:37:36 PM7/10/09
to native-cli...@googlegroups.com
+-1
sadly the alternative to scons is not make but automake
which I find even more impossible to deal with.
However, if you just want to build a nacl module we have some examples
using makefiles in tests/, e.g. awk
Robert
sadly the alternative to scons is not make but automake
which I find even more impossible to deal with.
However, if you just want to build a nacl module we have some examples
using makefiles in tests/, e.g. awk
Robert
Rick R
Jul 10, 2009, 10:22:11 PM7/10/09
to native-cli...@googlegroups.com
Hello,
I don't want to start an off topic religous war, but I disagree completely. Scons is succinct, flexible, and more portable than the automake tools[1]
The only real advantage automake has over scons is that more people know automake. Frankly, that's not good enough for me.
The industry needs to move on eventually.
As far as help goes: the Scons User Guide seems like a great place to start: http://www.scons.org/doc/HTML/scons-user/book1.html
It is very thorough. In addition, I don't think there is a person on this planet that would say that the Make language is easier to understand than Python.
[1] - Primarily due to windows support.
--
"The greatest obstacle to discovering the shape of the earth, the continents, and the oceans was not ignorance but the illusion of knowledge."
- Daniel J. Boorstin
On Fri, Jul 10, 2009 at 4:56 PM, Daniel Monteiro <montei...@gmail.com> wrote:
as much as it is also PITA, GNU make is quite portable and standard...
I don't want to start an off topic religous war, but I disagree completely. Scons is succinct, flexible, and more portable than the automake tools[1]
The only real advantage automake has over scons is that more people know automake. Frankly, that's not good enough for me.
The industry needs to move on eventually.
with the scons, I feel quite lost, as I know nothing about python and dont know where to look for help.
As far as help goes: the Scons User Guide seems like a great place to start: http://www.scons.org/doc/HTML/scons-user/book1.html
It is very thorough. In addition, I don't think there is a person on this planet that would say that the Make language is easier to understand than Python.
[1] - Primarily due to windows support.
"The greatest obstacle to discovering the shape of the earth, the continents, and the oceans was not ignorance but the illusion of knowledge."
- Daniel J. Boorstin
Daniel Monteiro
Jul 10, 2009, 11:00:19 PM7/10/09
to native-cli...@googlegroups.com
You're probably right. The problem was that , to me, scons was a internal google thing.
Didn't know there was a website about it. So its time for me to shut up and learn it. thanks!
[]s
Didn't know there was a website about it. So its time for me to shut up and learn it. thanks!
[]s
2009/7/10 Rick R <rick.ri...@gmail.com>
Simon
Jul 12, 2009, 2:42:16 PM7/12/09
to Native Client Discuss
As a developer I view NaCl as more important than Chrome OS because I
could care less about what OS the user is running. What I have always
needed is a way to run my applications on any OS. I want to be able
to build my applications an know that whatever OS the user has they
can still run my application and that could happen if NaCl becomes
part of the major browsers. In fact I hope to see the day when
Python , Delphi, Purebasic, Realbasic, Eiffel, Xharbour or whatever
your favorite development language can all be used to build apps for
the NaCl. I also hope that at least one good Visual Development IDE
can be run as a NaCl app so that I could just sit down at a
workstation any where and access a web browser to begin development.
Therefore, I really hope NaCl gets traction and is not abandoned
before it reaches its full potential. Chrome OS may be nice someday
but I do not see it replacing other OSes so the need for Nacl still
exists.
Simon
could care less about what OS the user is running. What I have always
needed is a way to run my applications on any OS. I want to be able
to build my applications an know that whatever OS the user has they
can still run my application and that could happen if NaCl becomes
part of the major browsers. In fact I hope to see the day when
Python , Delphi, Purebasic, Realbasic, Eiffel, Xharbour or whatever
your favorite development language can all be used to build apps for
the NaCl. I also hope that at least one good Visual Development IDE
can be run as a NaCl app so that I could just sit down at a
workstation any where and access a web browser to begin development.
Therefore, I really hope NaCl gets traction and is not abandoned
before it reaches its full potential. Chrome OS may be nice someday
but I do not see it replacing other OSes so the need for Nacl still
exists.
Simon
Greg Landrum
Jul 13, 2009, 2:34:32 AM7/13/09
to native-cli...@googlegroups.com
On Fri, Jul 10, 2009 at 4:26 PM, Brad Chen<brad...@google.com> wrote:
> Thanks for the feedback. Personally I don't know of any build systems I
> like. We need something very portable and maintainable. What kind of build
> system would you suggest?
> Thanks for the feedback. Personally I don't know of any build systems I
> like. We need something very portable and maintainable. What kind of build
> system would you suggest?
FWIW: the boost community, which has some pretty broad portability and
flexibility requirements, is starting to support cmake. I'm waiting
until that support is "production ready" to look into it, so I can't
speak to how approachable or maintainable it is, but it will hopefully
be better than the current system boost uses (based on jam).
The boost experience leads me to make one request/suggestion to the
NaCl team: when making this decision, please take the demands you will
be making on clients of the system into account. The boost build
system is a good example of something that serves the needs of its
developers very well, but that can be somewhat hostile to clients.
Certain boost libraries really require the client to also be using
bjam, and this can be a real barrier. I'm not sure what the solution
to this is, but I doubt that it's another "smaller market share" build
system like scons. cmake/automake may be inferior in terms of
flexibility, maintainability, and features, but by switching to
something less common you force every client to learn your build
system and, probably, to cobble together a parallel build system for
their software. And that's something few people enjoy.
-greg
Ian Lawrence
Jul 13, 2009, 7:40:38 AM7/13/09
to native-cli...@googlegroups.com
Hi
> Thanks for the feedback. Personally I don't know of any build systems I
> like. We need something very portable and maintainable. What kind of build
> system would you suggest?
> Thanks for the feedback. Personally I don't know of any build systems I
> like. We need something very portable and maintainable. What kind of build
> system would you suggest?
how about qmake then [1]?
I have used it a few times and it seems quite nice and straightforward
Ian
[1] http://doc.trolltech.com/4.2/qmake-manual.html
--
Reply all
Reply to author
Forward
0 new messages