It looks like the model B boards are now in manufacture. http://www.raspberrypi.org/archives/509
There are only 10k being made being made in this batch and demand is really high, so I doubt they'll last longer than a few minutes.
With only 256MB RAM available, I doubt Windows 8 will ever run on it although Windows Embedded Compact 7 might.
I know the reactos arm port is still a way off, but this could be a golden opportunity for reactos.
At $25 per computer, they're gonna sell hundreds of thousands of these things and most buyers will be enthusiasts/developers.
Ged.
ROS needs more devs urgently....
On Wed, Jan 11, 2012 at 11:18 AM, Ged Murphy gedmurphy.maillists@gmail.comwrote:
It looks like the model B boards are now in manufacture. http://www.raspberrypi.org/archives/509****
There are only 10k being made being made in this batch and demand is really high, so I doubt they’ll last longer than a few minutes.****
With only 256MB RAM available, I doubt Windows 8 will ever run on it although Windows Embedded Compact 7 might.****
I know the reactos arm port is still a way off, but this could be a golden opportunity for reactos.****
At $25 per computer, they’re gonna sell hundreds of thousands of these things and most buyers will be enthusiasts/developers.****
Ged.****
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
It's a generation-lagging ARM11 -- Windows and iOS don't support these kind of chips anymore (called ARMv6) because of major lacking functionality. The ARMv6K (which I'm not sure the Pi uses) is probably the minimum you'd want to use, and I know the ROS ARM port was retargeted to ARMv7 which has been out for almost 3-4 years now.
The PandaBoard, which is 179$, so definitely more expensive, is a much better platform for such a port -- it's an A9/v7 (successor to A8/v7, successor to ARMv6K, successor to ARM6...) and has dual-core, 1GB of RAM, a GPU, a DSP, and more... still a bargain for 179$ if you ask me though.
Best regards, Alex Ionescu
On Wed, Jan 11, 2012 at 11:18 AM, Ged Murphy gedmurphy.maillists@gmail.comwrote:
It looks like the model B boards are now in manufacture. http://www.raspberrypi.org/archives/509****
There are only 10k being made being made in this batch and demand is really high, so I doubt they’ll last longer than a few minutes.****
With only 256MB RAM available, I doubt Windows 8 will ever run on it although Windows Embedded Compact 7 might.****
I know the reactos arm port is still a way off, but this could be a golden opportunity for reactos.****
At $25 per computer, they’re gonna sell hundreds of thousands of these things and most buyers will be enthusiasts/developers.****
Ged.****
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
According to Wikipedia the Raspberry Pi uses the ARM1176JZF-S core which is an ARMv6Z architecture. It should be similar to the ARMv6K as it most notably lacks multi-core support. It's still an old architecture, of course, and I agree that the Cortex A-series is a much better choice as a development platform, whether it's the currently popular A8/A9 or the upcoming A15.
Maya
(2012/01/11 12:20), Alex Ionescu wrote:
It's a generation-lagging ARM11 -- Windows and iOS don't support these kind of chips anymore (called ARMv6) because of major lacking functionality. The ARMv6K (which I'm not sure the Pi uses) is probably the minimum you'd want to use, and I know the ROS ARM port was retargeted to ARMv7 which has been out for almost 3-4 years now.
The PandaBoard, which is 179$, so definitely more expensive, is a much better platform for such a port -- it's an A9/v7 (successor to A8/v7, successor to ARMv6K, successor to ARM6...) and has dual-core, 1GB of RAM, a GPU, a DSP, and more... still a bargain for 179$ if you ask me though.
Best regards, Alex Ionescu
On Wed, Jan 11, 2012 at 11:18 AM, Ged Murphy <gedmurphy.maillists@gmail.com mailto:gedmurphy.maillists@gmail.com> wrote:
It looks like the model B boards are now in manufacture. http://www.raspberrypi.org/archives/509 There are only 10k being made being made in this batch and demand is really high, so I doubt they'll last longer than a few minutes. With only 256MB RAM available, I doubt Windows 8 will ever run on it although Windows Embedded Compact 7 might. I know the reactos arm port is still a way off, but this could be a golden opportunity for reactos. At $25 per computer, they're gonna sell hundreds of thousands of these things and most buyers will be enthusiasts/developers. Ged. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org <mailto:Ros-dev@reactos.org> http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On Wed, Jan 11, 2012 at 12:20 PM, Alex Ionescu ionucu@videotron.ca wrote:
It's a generation-lagging ARM11 -- Windows and iOS don't support these kind of chips anymore (called ARMv6) because of major lacking functionality. The ARMv6K (which I'm not sure the Pi uses) is probably the minimum you'd want to use, and I know the ROS ARM port was retargeted to ARMv7 which has been out for almost 3-4 years now.
The PandaBoard, which is 179$, so definitely more expensive, is a much better platform for such a port -- it's an A9/v7 (successor to A8/v7, successor to ARMv6K, successor to ARM6...) and has dual-core, 1GB of RAM, a GPU, a DSP, and more... still a bargain for 179$ if you ask me though.
Best regards, Alex Ionescu
I would think that the raspberrypi pi is an excellent "base" platform for the ARM port of ReactOS, it's a board designed and oriented to be affordable and help (young) students to get into development, that means it's main objective is to have a couple of them in every classroom possible, and I'm sure most teachers would be more willing to include something like that in their classes if they could just give the students something that feels familiar with what they have at home(windows most of the time). The way I see it, when you have only a couple of hours per week to teach kids how to program, teaching them the basics of linux and dealing with linux specific problems could be a deal breaker for a lot of teachers, but if they were to have a ""windows-like"" environment and lightweight IDE in a image that "just works" out of the box, I think a lot of teachers would be willing to give it a try.
Apart from that, while the pandaboard is great for the price(I bought a beagleboard for that money a couple of years back and I still think it was a good deal), the raspberrypi pi falls under a "impulse buy" price tag and will provably sell hundreds/thousands more than the pandaboard, making it a more affordable and widely available way to get ReactOS to as many new users(and hopefully, developers) as possible.
Also, in the hobbyist front, those kind of users are usually more willing to put up with alpha/beta quality software and help with bug reports and generally get more involved with the community.
Of course I'm not dev, regular irc/forum user or anything and I might be terribly misinformed(or clueless) about a lot of things ReactOS related.
I thought Windows supported v5 - v7?
Anyway, I realise that the Raspberry Pi uses the dated v6 architecture, but the killer thing here is the $25 price tag.
There's also the BeagleBoard which is slightly cheaper than the PandaBoard, and also uses the A8/v7 chip. But at $149 I really don't see it shifting the same number of units as the raspberry boards. I already know quite a lot of people who are wanting to personally buy quite a few for fun and potential uses.
Maybe the development effort for a v6 port isn't worth it, but I think it's worth keeping an eye on the sales figures because the demand for these things seems huge. Potentially, that's a large number of developers which might be attracted to reactos.
Ged
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Alex Ionescu Sent: 11 January 2012 11:20 To: ReactOS Development List Subject: Re: [ros-dev] Rasberry Pi
It's a generation-lagging ARM11 -- Windows and iOS don't support these kind of chips anymore (called ARMv6) because of major lacking functionality. The ARMv6K (which I'm not sure the Pi uses) is probably the minimum you'd want to use, and I know the ROS ARM port was retargeted to ARMv7 which has been out for almost 3-4 years now.
The PandaBoard, which is 179$, so definitely more expensive, is a much better platform for such a port -- it's an A9/v7 (successor to A8/v7, successor to ARMv6K, successor to ARM6...) and has dual-core, 1GB of RAM, a GPU, a DSP, and more... still a bargain for 179$ if you ask me though.
Best regards, Alex Ionescu
On Wed, Jan 11, 2012 at 11:18 AM, Ged Murphy gedmurphy.maillists@gmail.com wrote:
It looks like the model B boards are now in manufacture. http://www.raspberrypi.org/archives/509
There are only 10k being made being made in this batch and demand is really high, so I doubt they'll last longer than a few minutes.
With only 256MB RAM available, I doubt Windows 8 will ever run on it although Windows Embedded Compact 7 might.
I know the reactos arm port is still a way off, but this could be a golden opportunity for reactos.
At $25 per computer, they're gonna sell hundreds of thousands of these things and most buyers will be enthusiasts/developers.
Ged.
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
If the Wikipedia page on ARM 11 is to be believed (http://en.wikipedia.org/wiki/ARM11), then even the original Nvidia Tegra uses this architecture, but aside from the Raspberry Pi I am not aware of any ARM11-based platform out there which might be useful for ROS, unless someone wants to run it on a smartphone.
I think at this point one has to look at the features provided by the ARMv6Z architecture and see whether it suffices for ROS's ARM port. If it's too much of a bother to work around issues, then don't use it.
Maya
(2012/01/11 13:41), Ged Murphy wrote:
I thought Windows supported v5 -- v7?
Anyway, I realise that the Raspberry Pi uses the dated v6 architecture, but the killer thing here is the $25 price tag.
There's also the BeagleBoard which is slightly cheaper than the PandaBoard, and also uses the A8/v7 chip. But at $149 I really don't see it shifting the same number of units as the raspberry boards. I already know quite a lot of people who are wanting to personally buy quite a few for fun and potential uses.
Maybe the development effort for a v6 port isn't worth it, but I think it's worth keeping an eye on the sales figures because the demand for these things seems huge. Potentially, that's a large number of developers which might be attracted to reactos.
Ged
*From:*ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] *On Behalf Of *Alex Ionescu *Sent:* 11 January 2012 11:20 *To:* ReactOS Development List *Subject:* Re: [ros-dev] Rasberry Pi
It's a generation-lagging ARM11 -- Windows and iOS don't support these kind of chips anymore (called ARMv6) because of major lacking functionality. The ARMv6K (which I'm not sure the Pi uses) is probably the minimum you'd want to use, and I know the ROS ARM port was retargeted to ARMv7 which has been out for almost 3-4 years now.
The PandaBoard, which is 179$, so definitely more expensive, is a much better platform for such a port -- it's an A9/v7 (successor to A8/v7, successor to ARMv6K, successor to ARM6...) and has dual-core, 1GB of RAM, a GPU, a DSP, and more... still a bargain for 179$ if you ask me though.
Best regards, Alex Ionescu
On Wed, Jan 11, 2012 at 11:18 AM, Ged Murphy <gedmurphy.maillists@gmail.com mailto:gedmurphy.maillists@gmail.com> wrote:
It looks like the model B boards are now in manufacture. http://www.raspberrypi.org/archives/509
There are only 10k being made being made in this batch and demand is really high, so I doubt they'll last longer than a few minutes.
With only 256MB RAM available, I doubt Windows 8 will ever run on it although Windows Embedded Compact 7 might.
I know the reactos arm port is still a way off, but this could be a golden opportunity for reactos.
At $25 per computer, they're gonna sell hundreds of thousands of these things and most buyers will be enthusiasts/developers.
Ged.
Ros-dev mailing list Ros-dev@reactos.org mailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Looks like Raspberry Pi will became very popular and it's a big chance for promoting ReactOS(if there will be an effort to port it to ARMv6Z). I'm not very familiar with multiplatform coding so correct me if i'm wrong: the main idea in porting ReactOS to ARM is replacing ASM code into C in parts where it's possible and use ARM ASM where it's not possible. So switching between different ARM versions should be mainly just matter of ASM syntax. And this is not so hard (afaik) as converting ASM to C.
2012/1/11, Maya Posch maya@nyanko.ws:
If the Wikipedia page on ARM 11 is to be believed (http://en.wikipedia.org/wiki/ARM11), then even the original Nvidia Tegra uses this architecture, but aside from the Raspberry Pi I am not aware of any ARM11-based platform out there which might be useful for ROS, unless someone wants to run it on a smartphone.
I think at this point one has to look at the features provided by the ARMv6Z architecture and see whether it suffices for ROS's ARM port. If it's too much of a bother to work around issues, then don't use it.
Maya
(2012/01/11 13:41), Ged Murphy wrote:
I thought Windows supported v5 -- v7?
Anyway, I realise that the Raspberry Pi uses the dated v6 architecture, but the killer thing here is the $25 price tag.
There's also the BeagleBoard which is slightly cheaper than the PandaBoard, and also uses the A8/v7 chip. But at $149 I really don't see it shifting the same number of units as the raspberry boards. I already know quite a lot of people who are wanting to personally buy quite a few for fun and potential uses.
Maybe the development effort for a v6 port isn't worth it, but I think it's worth keeping an eye on the sales figures because the demand for these things seems huge. Potentially, that's a large number of developers which might be attracted to reactos.
Ged
*From:*ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] *On Behalf Of *Alex Ionescu *Sent:* 11 January 2012 11:20 *To:* ReactOS Development List *Subject:* Re: [ros-dev] Rasberry Pi
It's a generation-lagging ARM11 -- Windows and iOS don't support these kind of chips anymore (called ARMv6) because of major lacking functionality. The ARMv6K (which I'm not sure the Pi uses) is probably the minimum you'd want to use, and I know the ROS ARM port was retargeted to ARMv7 which has been out for almost 3-4 years now.
The PandaBoard, which is 179$, so definitely more expensive, is a much better platform for such a port -- it's an A9/v7 (successor to A8/v7, successor to ARMv6K, successor to ARM6...) and has dual-core, 1GB of RAM, a GPU, a DSP, and more... still a bargain for 179$ if you ask me though.
Best regards, Alex Ionescu
On Wed, Jan 11, 2012 at 11:18 AM, Ged Murphy <gedmurphy.maillists@gmail.com mailto:gedmurphy.maillists@gmail.com> wrote:
It looks like the model B boards are now in manufacture. http://www.raspberrypi.org/archives/509
There are only 10k being made being made in this batch and demand is really high, so I doubt they'll last longer than a few minutes.
With only 256MB RAM available, I doubt Windows 8 will ever run on it although Windows Embedded Compact 7 might.
I know the reactos arm port is still a way off, but this could be a golden opportunity for reactos.
At $25 per computer, they're gonna sell hundreds of thousands of these things and most buyers will be enthusiasts/developers.
Ged.
Ros-dev mailing list Ros-dev@reactos.org mailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Yeah, the higher-level code should work without issues on the Pi considering it has an MMU and FPU. Converting the ASM to ARM-style ASM will be the key and I'm not qualified to make any assumptions there.
Are there any fundamental issues with porting the existing ASM code in ROS to an ARMv6Z architecture?
Maya
(2012/01/11 14:01), Igor Paliychuk wrote:
Looks like Raspberry Pi will became very popular and it's a big chance for promoting ReactOS(if there will be an effort to port it to ARMv6Z). I'm not very familiar with multiplatform coding so correct me if i'm wrong: the main idea in porting ReactOS to ARM is replacing ASM code into C in parts where it's possible and use ARM ASM where it's not possible. So switching between different ARM versions should be mainly just matter of ASM syntax. And this is not so hard (afaik) as converting ASM to C.
2012/1/11, Maya Poschmaya@nyanko.ws:
If the Wikipedia page on ARM 11 is to be believed (http://en.wikipedia.org/wiki/ARM11), then even the original Nvidia Tegra uses this architecture, but aside from the Raspberry Pi I am not aware of any ARM11-based platform out there which might be useful for ROS, unless someone wants to run it on a smartphone.
I think at this point one has to look at the features provided by the ARMv6Z architecture and see whether it suffices for ROS's ARM port. If it's too much of a bother to work around issues, then don't use it.
Maya
(2012/01/11 13:41), Ged Murphy wrote:
I thought Windows supported v5 -- v7?
Anyway, I realise that the Raspberry Pi uses the dated v6 architecture, but the killer thing here is the $25 price tag.
There's also the BeagleBoard which is slightly cheaper than the PandaBoard, and also uses the A8/v7 chip. But at $149 I really don't see it shifting the same number of units as the raspberry boards. I already know quite a lot of people who are wanting to personally buy quite a few for fun and potential uses.
Maybe the development effort for a v6 port isn't worth it, but I think it's worth keeping an eye on the sales figures because the demand for these things seems huge. Potentially, that's a large number of developers which might be attracted to reactos.
Ged
*From:*ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] *On Behalf Of *Alex Ionescu *Sent:* 11 January 2012 11:20 *To:* ReactOS Development List *Subject:* Re: [ros-dev] Rasberry Pi
It's a generation-lagging ARM11 -- Windows and iOS don't support these kind of chips anymore (called ARMv6) because of major lacking functionality. The ARMv6K (which I'm not sure the Pi uses) is probably the minimum you'd want to use, and I know the ROS ARM port was retargeted to ARMv7 which has been out for almost 3-4 years now.
The PandaBoard, which is 179$, so definitely more expensive, is a much better platform for such a port -- it's an A9/v7 (successor to A8/v7, successor to ARMv6K, successor to ARM6...) and has dual-core, 1GB of RAM, a GPU, a DSP, and more... still a bargain for 179$ if you ask me though.
Best regards, Alex Ionescu
On Wed, Jan 11, 2012 at 11:18 AM, Ged Murphy <gedmurphy.maillists@gmail.commailto:gedmurphy.maillists@gmail.com> wrote:
It looks like the model B boards are now in manufacture. http://www.raspberrypi.org/archives/509
There are only 10k being made being made in this batch and demand is really high, so I doubt they'll last longer than a few minutes.
With only 256MB RAM available, I doubt Windows 8 will ever run on it although Windows Embedded Compact 7 might.
I know the reactos arm port is still a way off, but this could be a golden opportunity for reactos.
At $25 per computer, they're gonna sell hundreds of thousands of these things and most buyers will be enthusiasts/developers.
Ged.
Ros-dev mailing list Ros-dev@reactos.orgmailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
WebOS is Linux-based OS and i don't think it can be more usefull in ReactOS development than any other Linux distro. It's very good that we got new open source OS but this should not turn into promoting another OS in ReactOS dev mailing list.
There is something interesting for me in all these (both webOS and Android). Kernel is just a kernel, I'm more interested in the higher level framework, and that's what could be theoretically used atop of ReactOS. However all of these are just speculations, first of all we need our kernel to be better than Linux in that case.
WBR, Aleksey. On 11.01.2012 17:49, Igor Paliychuk wrote:
WebOS is Linux-based OS and i don't think it can be more usefull in ReactOS development than any other Linux distro. It's very good that we got new open source OS but this should not turn into promoting another OS in ReactOS dev mailing list.
"our kernel to be better than Linux"
ugh... high expectations, indeed! :) that would be the ultimante push for ReactOS!
On Wed, Jan 11, 2012 at 3:57 PM, Aleksey Bragin aleksey@reactos.org wrote:
There is something interesting for me in all these (both webOS and Android). Kernel is just a kernel, I'm more interested in the higher level framework, and that's what could be theoretically used atop of ReactOS. However all of these are just speculations, first of all we need our kernel to be better than Linux in that case.
WBR, Aleksey.
On 11.01.2012 17:49, Igor Paliychuk wrote:
WebOS is Linux-based OS and i don't think it can be more usefull in ReactOS development than any other Linux distro. It's very good that we got new open source OS but this should not turn into promoting another OS in ReactOS dev mailing list.
______________________________**_________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/**mailman/listinfo/ros-devhttp://www.reactos.org/mailman/listinfo/ros-dev
It already is better than Linux!
(in design...)
2012/1/11 Javier Agustìn Fernàndez Arroyo elhoir@gmail.com:
"our kernel to be better than Linux"
ugh... high expectations, indeed! :) that would be the ultimante push for ReactOS!
On Wed, Jan 11, 2012 at 3:57 PM, Aleksey Bragin aleksey@reactos.org wrote:
There is something interesting for me in all these (both webOS and Android). Kernel is just a kernel, I'm more interested in the higher level framework, and that's what could be theoretically used atop of ReactOS. However all of these are just speculations, first of all we need our kernel to be better than Linux in that case.
WBR, Aleksey.
On 11.01.2012 17:49, Igor Paliychuk wrote:
WebOS is Linux-based OS and i don't think it can be more usefull in ReactOS development than any other Linux distro. It's very good that we got new open source OS but this should not turn into promoting another OS in ReactOS dev mailing list.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Given the way Linux is going at the moment (see http://news.cnet.com/8301-13505_3-10358024-16.html for example) I think I do not think those expectations will be too high in the near future. ;)
On Wed, 11 Jan 2012 16:10:54 +0100 Javier Agustìn Fernàndez Arroyo elhoir@gmail.com wrote:
"our kernel to be better than Linux"
ugh... high expectations, indeed! :) that would be the ultimante push for ReactOS!
On Wed, Jan 11, 2012 at 3:57 PM, Aleksey Bragin aleksey@reactos.org wrote:
There is something interesting for me in all these (both webOS and Android). Kernel is just a kernel, I'm more interested in the higher level framework, and that's what could be theoretically used atop of ReactOS. However all of these are just speculations, first of all we need our kernel to be better than Linux in that case.
WBR, Aleksey.
On 11.01.2012 17:49, Igor Paliychuk wrote:
WebOS is Linux-based OS and i don't think it can be more usefull in ReactOS development than any other Linux distro. It's very good that we got new open source OS but this should not turn into promoting another OS in ReactOS dev mailing list.
______________________________**_________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/**mailman/listinfo/ros-devhttp://www.reactos.org/mailman/listinfo/ros-dev
Uh, that's strange... Not only is that old news, I wonder whether you've read TFA. It has an update at the bottom: *"One thing that I forgot to mention, but which is critical to the success of Linux, is that there really is no such thing as monolithic "Linux." Linux is highly modular and can be trimmed down/beefed up to fit a wide variety of applications...on the developers' terms, not Red Hat's, Novell's, Canonical's, etc. *
*So, unlike Windows, which can only be what Microsoft dictates, Linux can truly be all things to all people, as "fat" or as "skinny" as the developer wants it to be. Ubuntu is obese compared to sub-100 KB uClinux distributions, for example. Both serve different, and useful, purposes."*
That being said, I love ReactOS and I sure hope that it will actually be viable in the near future. From there on I'm expecting the same kind of exponential growth (initially) as Linux has seen. In technical terms that is.
Op 17-1-2012 12:02, Adam schreef:
Given the way Linux is going at the moment (see http://news.cnet.com/8301-13505_3-10358024-16.html for example) I think I do not think those expectations will be too high in the near future. ;)
On Wed, 11 Jan 2012 16:10:54 +0100 Javier Agustìn Fernàndez Arroyoelhoir@gmail.com wrote:
"our kernel to be better than Linux"
ugh... high expectations, indeed! :) that would be the ultimante push for ReactOS!
On Wed, Jan 11, 2012 at 3:57 PM, Aleksey Braginaleksey@reactos.org wrote:
There is something interesting for me in all these (both webOS and Android). Kernel is just a kernel, I'm more interested in the higher level framework, and that's what could be theoretically used atop of ReactOS. However all of these are just speculations, first of all we need our kernel to be better than Linux in that case.
WBR, Aleksey.
On 11.01.2012 17:49, Igor Paliychuk wrote:
WebOS is Linux-based OS and i don't think it can be more usefull in ReactOS development than any other Linux distro. It's very good that we got new open source OS but this should not turn into promoting another OS in ReactOS dev mailing list.
______________________________**_________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/**mailman/listinfo/ros-devhttp://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Old, but relevant in today's world. Let's face it... the mainline kernel is getting huge.
Let's have a look at the update:
*"One thing that I forgot to mention, but which is critical to the success of Linux, is that there really is no such thing as monolithic "Linux." Linux is highly modular and can be trimmed down/beefed up to fit a wide variety of applications...on the developers' terms, not Red Hat's, Novell's, Canonical's, etc. *
"on the *developers'* terms" - this effectively means "on the terms of who wrote the software" - not "on the user's terms" - so you'll still get some bloated distros out there. And who says Linux is getting smaller?
*So, unlike Windows, which can only be what Microsoft dictates, Linux can truly be all things to all people, as "fat" or as "skinny" as the developer wants it to be. Ubuntu is obese compared to sub-100 KB uClinux distributions, for example. Both serve different, and useful, purposes."*
Again, "*as the developer wants it to be*" - And yes, this goes for Windows too. Microsoft probably wants it to be bloated, so it makes it bloated.
Though I can agree with "So, unlike Windows, which can only be what Microsoft dictates, ..." - but bear in mind that when it comes to Windows then Microsoft is the developer anyway. It's on the developers' terms.
I'd love to see the kernel uClinux uses... I reckon it's not the mainline kernel, but a modified version of it. Again... it's up to the *developer* as the quote above mentioned.
Just go over to http://kernel.org/ - the source code for the Linux *kernel* in *compressed* form is 74MB plus! And that is compressed by the way. You'd need to have a very stripped down kernel to the max. Which would have been fine if it was "highly modular" as it is claimed.
Personally I'm happy seeing ReactOS the way it is going and I think they're taking the right direction. The last thing ReactOS needs is to listen to some kid going about some super fantastic UI (or other Linux-specific feature) present in Linux and attempting to say it should be in ReactOS as an "improvement" of some sort.
On Tue, 17 Jan 2012 12:25:47 +0100 Ameen Ross a.ross@amdev.eu wrote:
Uh, that's strange... Not only is that old news, I wonder whether you've read TFA. It has an update at the bottom: *"One thing that I forgot to mention, but which is critical to the success of Linux, is that there really is no such thing as monolithic "Linux." Linux is highly modular and can be trimmed down/beefed up to fit a wide variety of applications...on the developers' terms, not Red Hat's, Novell's, Canonical's, etc. *
*So, unlike Windows, which can only be what Microsoft dictates, Linux can truly be all things to all people, as "fat" or as "skinny" as the developer wants it to be. Ubuntu is obese compared to sub-100 KB uClinux distributions, for example. Both serve different, and useful, purposes."*
That being said, I love ReactOS and I sure hope that it will actually be viable in the near future. From there on I'm expecting the same kind of exponential growth (initially) as Linux has seen. In technical terms that is.
Op 17-1-2012 12:02, Adam schreef:
Given the way Linux is going at the moment (see http://news.cnet.com/8301-13505_3-10358024-16.html for example) I think I do not think those expectations will be too high in the near future. ;)
On Wed, 11 Jan 2012 16:10:54 +0100 Javier Agustìn Fernàndez Arroyoelhoir@gmail.com wrote:
"our kernel to be better than Linux"
ugh... high expectations, indeed! :) that would be the ultimante push for ReactOS!
On Wed, Jan 11, 2012 at 3:57 PM, Aleksey Braginaleksey@reactos.org wrote:
There is something interesting for me in all these (both webOS and Android). Kernel is just a kernel, I'm more interested in the higher level framework, and that's what could be theoretically used atop of ReactOS. However all of these are just speculations, first of all we need our kernel to be better than Linux in that case.
WBR, Aleksey.
On 11.01.2012 17:49, Igor Paliychuk wrote:
WebOS is Linux-based OS and i don't think it can be more usefull in ReactOS development than any other Linux distro. It's very good that we got new open source OS but this should not turn into promoting another OS in ReactOS dev mailing list.
______________________________**_________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/**mailman/listinfo/ros-devhttp://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Op 18-1-2012 13:27, Adam schreef:
Old, but relevant in today's world. Let's face it... the mainline kernel is getting huge.
Agree, but a good portion of that is actually drivers and many other things that can easily be left out.
"on the *developers'* terms" - this effectively means "on the terms of who wrote the software" - not "on the user's terms" - so you'll still get some bloated distros out there.
If you're running a distro with a kernel too bloated to your tastes you can switch to a more light-weight distro. Not the case with Windows, although the question of whether or not that's a good thing is a whole debate of itself.
Again, "*as the developer wants it to be*" - And yes, this goes for Windows too. Microsoft probably wants it to be bloated, so it makes it bloated.
The difference here is that with Windows, Microsoft is the only developer and with Linux, anyone doing an embedded appliance or a distro has that freedom.
Though I can agree with "So, unlike Windows, which can only be what Microsoft dictates, ..." - but bear in mind that when it comes to Windows then Microsoft is the developer anyway. It's on the developers' terms.
...isn't that exactly the point?
I'd love to see the kernel uClinux uses... I reckon it's not the mainline kernel, but a modified version of it. Again... it's up to the *developer* as the quote above mentioned.
I'm surprised you've never heard about it. Although it does confirm my suspision that you didn't thoroughly read the article ;) Lots of stuff runs uCLinux actually, mostly embedded d.
Just go over to http://kernel.org/ - the source code for the Linux *kernel* in *compressed* form is 74MB plus! And that is compressed by the way. You'd need to have a very stripped down kernel to the max. Which would have been fine if it was "highly modular" as it is claimed.
Your tone sounds as if you oppose the statement in the article that Linux is highly modular.
Personally I'm happy seeing ReactOS the way it is going and I think they're taking the right direction. The last thing ReactOS needs is to listen to some kid going about some super fantastic UI (or other Linux-specific feature) present in Linux and attempting to say it should be in ReactOS as an "improvement" of some sort.
Did anything I say imply my opinion is contrary to that? Unless you read it to mean something else than I intended, that's impossible.
The NT kernel just takes a different approach than the Linux kernel, concequently the ReactOS project takes a different approach than the Linux distros. Not any approach is "right" or "wrong", they're just different approaches catering to different requirements.
It's sort of like the font rendering issue. Mac OS does pretty rendering, but Microsoft chose rasterized/readable rendering. Neither is better than the other, just a different approach to the problem.
On Wed, 18 Jan 2012 14:22:59 +0100 Ameen Ross a.ross@amdev.eu wrote:
Op 18-1-2012 13:27, Adam schreef:
Old, but relevant in today's world. Let's face it... the mainline kernel is getting huge.
Agree, but a good portion of that is actually drivers and many other things that can easily be left out.
Although that would require recompiling the kernel just to install/uninstall drivers. I do understand loadable modules are supported but I'm not sure this applies to drivers. And if it does, I doubt it would apply to all drivers.
"on the *developers'* terms" - this effectively means "on the terms of who wrote the software" - not "on the user's terms" - so you'll still get some bloated distros out there.
If you're running a distro with a kernel too bloated to your tastes you can switch to a more light-weight distro. Not the case with Windows, although the question of whether or not that's a good thing is a whole debate of itself.
Again, "*as the developer wants it to be*" - And yes, this goes for Windows too. Microsoft probably wants it to be bloated, so it makes it bloated.
The difference here is that with Windows, Microsoft is the only developer and with Linux, anyone doing an embedded appliance or a distro has that freedom.
Though I can agree with "So, unlike Windows, which can only be what Microsoft dictates, ..." - but bear in mind that when it comes to Windows then Microsoft is the developer anyway. It's on the developers' terms.
...isn't that exactly the point?
And of course, let us not forget that many corporations (Microsoft, IBM, etc) also contributed to Linux - in addition it is possible to develop device drivers for Microsoft Windows too.
In any case I think this article "update" seems to have done a great job at distracting both of us from the issue I was talking about:
From my original email:
"Given the way Linux is going at the moment (see http://news.cnet.com/8301-13505_3-10358024-16.html for example) I think I do not think those expectations will be too high in the near future. ;)"
It had nothing to do with "how the developers could customize things" or comparisons with Microsoft Windows - I was making a prediction for the future of the ReactOS kernel vs Linux kernel based on the above source. I never mentioned the "update" because *it is irrelevant* to my point, and appears to serve as a distraction.
If Linus Torvalds, the creator of the Linux kernel, admitted it is getting bloaty, then perhaps this means something for the direction the Linux kernel is going? I mean who cannot expect to see an increase of code size as new features are added. Particularly those which many won't be using.
I cannot see how this "update" at the end has any relevance to the article.
I'd love to see the kernel uClinux uses... I reckon it's not the mainline kernel, but a modified version of it. Again... it's up to the *developer* as the quote above mentioned.
I'm surprised you've never heard about it. Although it does confirm my suspision that you didn't thoroughly read the article ;) Lots of stuff runs uCLinux actually, mostly embedded d.
I have indeed heard about uCLinux - I was suggesting it probably doesn't even use the mainline kernel, otherwise it would definitely be bigger than 100KB then.
As for me not thoroughly reading the article... I think I did read the whole article but happened to dismiss the update because it has *nothing to do with the article* - saying things like "oh but linux is highly modular and developers can customize it to make it not so bloaty" does not do well and appears to be more of an attempt to hide the issue.
If you had told me I hadn't read all of the comments, however, yes I would agree.
Just go over to http://kernel.org/ - the source code for the Linux *kernel* in *compressed* form is 74MB plus! And that is compressed by the way. You'd need to have a very stripped down kernel to the max. Which would have been fine if it was "highly modular" as it is claimed.
Your tone sounds as if you oppose the statement in the article that Linux is highly modular.
I suppose bunching lots of bells and whistles in the kernel (file systems, drivers, pseudo-devices, etc) and also sticking "support" for loadable modules (and LSM) alone makes it "highly modular" then? Well yes it *supports* modules, but I'd hardly call it "highly modular" the way it's going.
Personally I'm happy seeing ReactOS the way it is going and I think they're taking the right direction. The last thing ReactOS needs is to listen to some kid going about some super fantastic UI (or other Linux-specific feature) present in Linux and attempting to say it should be in ReactOS as an "improvement" of some sort.
Did anything I say imply my opinion is contrary to that? Unless you read it to mean something else than I intended, that's impossible.
I cannot remember saying that your opinion was contrary to that. Can you point out where I said or implied this?
The NT kernel just takes a different approach than the Linux kernel, concequently the ReactOS project takes a different approach than the Linux distros. Not any approach is "right" or "wrong", they're just different approaches catering to different requirements.
It's sort of like the font rendering issue. Mac OS does pretty rendering, but Microsoft chose rasterized/readable rendering. Neither is better than the other, just a different approach to the problem.
That may be true, but some approaches are better than others, for a particular purpose. Windows and Linux have one thing in common: they both have desktop and server markets. For both areas, they both do things better than each other. Windows has a better permissions control system than Linux "user group owner" permissions. Linux supports more protocols so interoperability is there, and SSH makes it easy to manage remotely via command line.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On January 18, 2012 at 2:54 PM Adam geekdundee@gmail.com wrote:
Although that would require recompiling the kernel just to install/uninstall drivers. I do understand loadable modules are supported but I'm not sure this applies to drivers. And if it does, I doubt it would apply to all drivers.
No recompile. It applies to all drivers for PCI and USB devices and huge bunch of other things. Almost everything is loadable, including all routing tricks.
job at distracting both of us from the issue I was talking about:
Very much.
If Linus Torvalds, the creator of the Linux kernel, admitted it is getting bloaty, then perhaps this means something for the direction the Linux kernel is going? I mean who cannot expect to see an increase of code size as new features are added. Particularly those which many won't be using.
Oh, true.
I have indeed heard about uCLinux - I was suggesting it probably doesn't even use the mainline kernel, otherwise it would definitely be bigger than 100KB then.
uCLinux uses the mainline kernel. And is never as small as 100kb. Embedded systems today using uCLinux has at least 2 megabytes of RAM, often 8 or more. The rest I am just cutting... what are we discussing here exactly? If I go back to the topic somewhat: As for HP WebOS on ReactOS - if some random guy wants to port it to run atop of Reactos/Windows instead of Linux, good for him. I don't see active ReactOS developers dropping everything they are doing to do that instead, so you don't need to fear that. best regards, Jakob
On 18.01.2012 18:14, Jakob Eriksson wrote:
On January 18, 2012 at 2:54 PM Adamgeekdundee@gmail.com wrote:
Although that would require recompiling the kernel just to install/uninstall drivers. I do understand loadable modules are supported but I'm not sure this applies to drivers. And if it does, I doubt it would apply to all drivers.
No recompile. It applies to all drivers for PCI and USB devices and huge bunch of other things. Almost everything is loadable, including all routing tricks.
It's a loadable module, yes, and it loads dynamically indeed. There is one issue though: the binary driver itself has to be recompiled with every Linux kernel update. I personally experience this when I patch the bt8x8 video capture device driver for my 8 ports capturing card, every time I manually patch source code to include my specific hardware (oh yes, it's already 5 years old, it's being sold in every hardware shop, but still it's not in the linux kernel).
P.S. Proper answer from Linux team would be "We accept patches!" :-).
WBR, Aleksey.
Am 18.01.2012 16:06, schrieb Aleksey Bragin:
On 18.01.2012 18:14, Jakob Eriksson wrote:
On January 18, 2012 at 2:54 PM Adamgeekdundee@gmail.com wrote:
Although that would require recompiling the kernel just to install/uninstall drivers. I do understand loadable modules are supported but I'm not sure this applies to drivers. And if it does, I doubt it would apply to all drivers.
No recompile. It applies to all drivers for PCI and USB devices and huge bunch of other things. Almost everything is loadable, including all routing tricks.
It's a loadable module, yes, and it loads dynamically indeed. There is one issue though: the binary driver itself has to be recompiled with every Linux kernel update. I personally experience this when I patch the bt8x8 video capture device driver for my 8 ports capturing card, every time I manually patch source code to include my specific hardware (oh yes, it's already 5 years old, it's being sold in every hardware shop, but still it's not in the linux kernel).
P.S. Proper answer from Linux team would be "We accept patches!" :-).
Well... I DID sent in patches to get my video capture device supported and since 2.9.38 I can finally use it without manually compiling the "standalone variant" provided by the driver's maintainer ;)
Regards, Sven
Am 18.01.2012 16:06, schrieb Aleksey Bragin:
P.S. Proper answer from Linux team would be "We accept patches!" :-).
Maybe that doesn't match reality. I remember reading an article by some guy who wrote lots of patches for the scheduler and finally rewrote the whole thing. It proved to perform better than the original scheduler and many people were using it, yet it never got incorporated into the mainline kernel. At some point some other guy rewrote the original scheduler doing basically the same thing that he had developed earlier and at that point he quit linux development.
You do know that there were actually 2 sides to that story?
On 01/18/2012 07:18 PM, Timo Kreuzer wrote:
Am 18.01.2012 16:06, schrieb Aleksey Bragin:
P.S. Proper answer from Linux team would be "We accept patches!" :-).
Maybe that doesn't match reality. I remember reading an article by some guy who wrote lots of patches for the scheduler and finally rewrote the whole thing. It proved to perform better than the original scheduler and many people were using it, yet it never got incorporated into the mainline kernel. At some point some other guy rewrote the original scheduler doing basically the same thing that he had developed earlier and at that point he quit linux development.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ah, politics. ;)
Linus Torvalds wouldn't even let a kernel debugger make it into the kernel for a long time because he seemed to be under the impression that they are for sissies.
http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.html http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg01462.html (note: currently blacked out to try and rais awareness that some shitheads in the US Congress want to censor the internet [with SOPA and PIPA legislation] - try after ~12 hours)
(that being said the reply by Ameen Ross may have merit - there are probably two sides to the story - the LKML should be able to tell)
On Wed, 18 Jan 2012 19:18:48 +0100 Timo Kreuzer timo.kreuzer@web.de wrote:
Am 18.01.2012 16:06, schrieb Aleksey Bragin:
P.S. Proper answer from Linux team would be "We accept patches!" :-).
Maybe that doesn't match reality. I remember reading an article by some guy who wrote lots of patches for the scheduler and finally rewrote the whole thing. It proved to perform better than the original scheduler and many people were using it, yet it never got incorporated into the mainline kernel. At some point some other guy rewrote the original scheduler doing basically the same thing that he had developed earlier and at that point he quit linux development.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
There's not much justification from a technical perspective for the behavior of the kernel maintainers in the CK patchset incident. One of the grad students that worked with my group did profiling of Linux kernel scheduling behaviors and he examined some of the work that happened. What it boiled down to was the CK patches were rejected by the guy responsible for the scheduler in Linux, said guy went and wrote his own implementation of the scheduling strategy from the CK patches which ended up doing a worse job than the CK patches, and that implementation was the one that got merged into the mainline. He found a whole lot of other crap in the scheduling behavior that were problematic as well but that's a different story entirely. There are plenty of cases in the Linux development world wherein ideology, politics, and ego have stood in the way of technical advancement or merit. By and large, the Linux kernel maintainers are not really developing or maintaining Linux for use by others, they are doing it for their own personal needs/desires. As far as I know, the kernel maintainers still resist the very idea of a pluggable scheduler architecture despite the advantages it would bring for various end-users because THEY themselves do not consider it to be necessary. The source code may be there, but if you can't get the changes you need into the mainline, then the cost of maintaining the feature you need approaches the unfeasible, at which point availability of source code is pretty much irrelevant.
On Wed, Jan 18, 2012 at 6:21 PM, Adam geekdundee@gmail.com wrote:
Ah, politics. ;)
Linus Torvalds wouldn't even let a kernel debugger make it into the kernel for a long time because he seemed to be under the impression that they are for sissies.
http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.html http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg01462.html (note: currently blacked out to try and rais awareness that some shitheads in the US Congress want to censor the internet [with SOPA and PIPA legislation] - try after ~12 hours)
(that being said the reply by Ameen Ross may have merit - there are probably two sides to the story - the LKML should be able to tell)
On Wed, 18 Jan 2012 19:18:48 +0100 Timo Kreuzer timo.kreuzer@web.de wrote:
Am 18.01.2012 16:06, schrieb Aleksey Bragin:
P.S. Proper answer from Linux team would be "We accept patches!" :-).
Maybe that doesn't match reality. I remember reading an article by some guy who wrote lots of patches for the scheduler and finally rewrote the whole thing. It proved to perform better than the original scheduler and many people were using it, yet it never got incorporated into the mainline kernel. At some point some other guy rewrote the original scheduler doing basically the same thing that he had developed earlier and at that point he quit linux development.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On January 19, 2012 at 3:38 AM Zachary Gorden drakekaizer666@gmail.com wrote:
end-users because THEY themselves do not consider it to be necessary. The source code may be there, but if you can't get the changes you
It's not perfect, but it's working. It's hard to argue with success. The day Linux is not good enough, it will be left behind for something else. //Jakob
On 19.01.2012 15:03, Jakob Eriksson wrote:
On January 19, 2012 at 3:38 AM Zachary Gordendrakekaizer666@gmail.com wrote:
end-users because THEY themselves do not consider it to be necessary. The source code may be there, but if you can't get the changes you
It's not perfect, but it's working. It's hard to argue with success. The day Linux is not good enough, it will be left behind for something else.
//Jakob
Something more than just this is involved. Example - FreeBSD. It also works, it has an even freer license but it's not as popular as Linux is.
WBR, Aleksey.
On January 19, 2012 at 12:06 PM Aleksey Bragin aleksey@reactos.org wrote:
On 19.01.2012 15:03, Jakob Eriksson wrote:
It's not perfect, but it's working. It's hard to argue with success. The day Linux is not good enough, it will be left behind for something else. //Jakob
Something more than just this is involved. Example - FreeBSD. It also works, it has an even freer license but it's not as popular as Linux is.
That is the reverse logic. I didn't mean "if it's good enough, the users will come". I meant "if it's bad enough, users will leave". best regards, Jakob
Am 19.01.2012 01:21, schrieb Adam:
Ah, politics. ;)
Linus Torvalds wouldn't even let a kernel debugger make it into the kernel for a long time because he seemed to be under the impression that they are for sissies.
Quote L. T.: "I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing."
/o\ MAAAN, I have rarely read so much BS in so few senteces. That guy must be completely retarded. No wonder linux sucks so much...
On January 19, 2012 at 9:15 PM Timo Kreuzer timo.kreuzer@web.de wrote:
Quote L. T.: "I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing."
/o\ MAAAN, I have rarely read so much BS in so few senteces. That guy must be completely retarded. No wonder linux sucks so much...
One or both you (L.T./T.K.) is trolling or being trolled... best regards, Jakob
This thread has gone way off course, please stop. On Jan 19, 2012 4:55 PM, "Jakob Eriksson" jakob@aurorasystems.eu wrote:
On January 19, 2012 at 9:15 PM Timo Kreuzer timo.kreuzer@web.de wrote:
Quote L. T.: "I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing."
/o\ MAAAN, I have rarely read so much BS in so few senteces. That guy must be completely retarded. No wonder linux sucks so much...
One or both you (L.T./T.K.) is trolling or being trolled...
best regards, Jakob
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
And almost noone really expressed any opinion about WebOS.
As for me, I find it very fascinating, though I was more inclined towards Android before Alexandre explained me WebOS user interface architecture.
Did WebOS finally open up the UI part of the source code? That's interesting, not their patched Linux kernel along with some nix-style libs.
WBR, Aleksey.
On 20.01.2012 1:57, WaxDragon wrote:
This thread has gone way off course, please stop.
On Jan 19, 2012 4:55 PM, "Jakob Eriksson" <jakob@aurorasystems.eu mailto:jakob@aurorasystems.eu> wrote:
On January 19, 2012 at 9:15 PM Timo Kreuzer <timo.kreuzer@web.de <mailto:timo.kreuzer@web.de>> wrote: > > Quote L. T.: "I don't think kernel development should be "easy". I do > not condone single-stepping through code to find the bug. I do not think > that extra visibility into the system is > necessarily a good thing." > > /o\ > MAAAN, I have rarely read so much BS in so few senteces. That guy must > be completely retarded. No wonder linux sucks so much... One or both you (L.T./T.K.) is trolling or being trolled... best regards, Jakob
All of webOS is to be opened up soon, like within the next few months. This also includes the UI and app frameworks, too.
On Sun, Jan 22, 2012 at 6:56 AM, Aleksey Bragin aleksey@reactos.org wrote:
And almost noone really expressed any opinion about WebOS.
As for me, I find it very fascinating, though I was more inclined towards Android before Alexandre explained me WebOS user interface architecture.
Did WebOS finally open up the UI part of the source code? That's interesting, not their patched Linux kernel along with some nix-style libs.
WBR, Aleksey.
On 20.01.2012 1:57, WaxDragon wrote:
This thread has gone way off course, please stop. On Jan 19, 2012 4:55 PM, "Jakob Eriksson" jakob@aurorasystems.eu wrote:
On January 19, 2012 at 9:15 PM Timo Kreuzer timo.kreuzer@web.de wrote:
Quote L. T.: "I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing."
/o\ MAAAN, I have rarely read so much BS in so few senteces. That guy must be completely retarded. No wonder linux sucks so much...
One or both you (L.T./T.K.) is trolling or being trolled...
best regards, Jakob
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Looks like Raspberry Pi will became very popular and it's a big chance for promoting ReactOS(if there will be an effort to port it to ARMv6Z). I'm not very familiar with multiplatform coding so correct me if i'm wrong: the main idea in porting ReactOS to ARM is replacing ASM code into C in parts where it's possible and use ARM ASM where it's not possible. So switching between different ARM versions should be mainly just matter of ASM syntax. And this is not so hard (afaik) as converting ASM to C.
Nope, there is much more work involved. There are big differences between x86 and ARM architectures so the port needs some rewrites, you can give a look to the ARM branch. Sadly seems to not be so easy.
Also the newer ARMs don't just have "new ASM instructions". There are major MMU changes, for example, as well as SMP support.
Best regards, Alex Ionescu
On Wed, Jan 11, 2012 at 2:51 PM, victor martinez vicmarcal@hotmail.comwrote:
Looks like Raspberry Pi will became very popular and it's a big chance for promoting ReactOS(if there will be an effort to port it to ARMv6Z). I'm not very familiar with multiplatform coding so correct me if i'm wrong: the main idea in porting ReactOS to ARM is replacing ASM code into C in parts where it's possible and use ARM ASM where it's not possible. So switching between different ARM versions should be mainly just matter of ASM syntax. And this is not so hard (afaik) as converting ASM to C.
Nope, there is much more work involved. There are big differences between x86 and ARM architectures so the port needs some rewrites, you can give a look to the ARM branch. Sadly seems to not be so easy.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Adam -
Aleksey Bragin -
Alex Ionescu -
Ameen Ross -
Andrew Faulds -
Artanis -
Conan Kudo (ニール・ゴンパ) -
Ged Murphy -
Igor Paliychuk -
Jakob Eriksson -
Javier Agustìn Fernàndez Arroyo -
Maya Posch -
Sven Barth -
Timo Kreuzer -
victor martinez -
WaxDragon -
Zachary Gorden -
Александр