Linux 3.7 Kernel To Support Multiple ARM Platforms

hypnosec writes with news that the Linux 3.7 kernel will support multiple ARM-based System on Chip platforms (Git commit page), writing "Up until now there has been a separate Linux kernel build for each of the ARM platforms or SoCs, which is one of the several problems when it comes to ARM based Linux. The merging of ARM multi-platform support into Linux 3.7 will put an end to this problem, enabling the new kernel to not only target multiple platforms but also be more in line with its x86 counterpart."

Comments

Obligatory Niven reference

[rossdee]

Gil Hamilton is one of Larry Nivens best characters

Re:Obligatory Niven reference

[Doc Ruby]

All the wireheads have been jonesing for multiple this kernel update.

Odd question - Apple A4?

[Penguinisto]

So... anyone thinking of tinkering with a kernel that supports the Apple ARM chips?

(been a long while since I bothered with ARM, so maybe something out there already works with it... dunno. Still, it'd be hella funny to walk around with an iPad that sports a Linux distro on it :) )

Re:Odd question - Apple A4?

[Anonymous Coward]

Android on the iPad would be SOMETHING :D

Re:Odd question - Apple A4?

[elfprince13]

Like....this?

Re:Odd question - Apple A4?

[Anonymous Coward]

I guess something like this has been done: http://www.idroidproject.org/

Re:Odd question - Apple A4?

[fuzzyfuzzyfungus]

I suspect that the scale of any processor/peripheral level weirdness(particularly if you are willing to accept values of 'works' that are closer to 'boots' than to 'runs with native performance') is relatively minor compared to the "designed only to run code signed by somebody other than you" problem. Bootloader locks aren't perfect, and have been circumvented on at least the older iDevices; but they certainly make portability a challenge.

Re:Odd question - Apple A4?

[Anonymous Coward]

A quote from Billy Madison popped into my head while reading your comment:

"Mr. [fuzzyfuzzyfungus], what you've just said is one of the most insanely idiotic things I have ever heard. At no point in your rambling, incoherent response were you even close to anything that could be considered a rational thought. Everyone in this room is now dumber for having listened to it. I award you no points, and may God have mercy on your soul."

Re:Odd question - Apple A4?

[unixisc]

Are the specs of the A4, A5, A6 even open that Linux can be ported there? I believe that they are genuine Apple only platforms. Although Apple could have achieved the same w/ PPC as well.

Re:Odd question - Apple A4?

[Anonymous Coward]

The ARM CPU itself is likely bog standard Cortex, And the GPU most likely Mali. Question is what other stuff is hiding around the SoC, and how to bring it all up in a stable manner. One of the decidedly beneficial things that MS mandates for their RT variant of WIndows 8 is that even ARM based products need to provide PCI device lookup capability. This is usually lacking on ARM SoCs, so there is no way to probe a bus and get a enumerated list of what is on it. You either know what is on there beforehand or you're out of luck.

Re:Odd question - Apple A4?

[Anonymous Coward]

The CPUs on first-gen (and 3G) were ARM11, not Cortex. 3GS and 4 were Cortex-A8, and 4S was a dual Cortex-A9 design.

iPhone 5 seems to have their custom-built core on it, but binary compatible with ARMv7, i.e. Cortex.

Graphics on all Apple chips to date have been from the devil, i.e. Imagination.

Clue wanted

[dbc]

“it is now possible to build one kernel that contains support for highbank, vexpress, mvebu, socfpga, and picoxcell. More platforms will be convered over in the next few releases."

What does that mean? I'm interested in Beagle/Panda variants and Raspberry Pi. The above quote doesn't yield any keyword hits in my wetware.

Re:Clue wanted

[Anonymous Coward]

Some of those aren't words. But I do know that beagles and pandas are types of dogs. Hope this helps!

Re:Clue wanted

[Anonymous Coward]

The basic infrastructure for supporting bcm2835 (the board used by raspberry pi) was just added a few days ago [1], so maybe 3.7 won't be fully functional on the pi, but it's getting there, I believe/hope.

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=11801e9de26992d37cb869cc74f389b6a7677e0e

Re:Clue wanted

[Anonymous Coward]

Those are different ARM based SoCs ("System on a chip"). The problem with the ARM platform is that ARM is not really a platform: The unifying aspect is the line of CPUs in the chip, but the SoCs come with different sets of peripherals. Even simple things like what GPIO (General Purpose IO) is connected to what LED or other function require a completely separate hardware configuration compiled into the kernel. On a PC, the kernel uses the BIOS and self-describing hardware to set everything up and choose the right drivers. No such thing exists on ARM. The kernel has to be told manually what's where. That's why you can't currently take a kernel which is compiled for one ARM SoC and use it on a different kind of ARM SoC. You're lucky if you can use the same kernel on the same ARM SoC in a different device that just happens to have everything wired up slightly differently. You may find that the GPIO that turns on the power LED on one system turns off USB power on another system. Then you need to patch the kernel or, if you want to have mainline support, register a new arc number and have yet another configuration added to the kernel. It's a fucking mess.

Re:Clue wanted

[jimicus]

In plain English, an ARM processor isn't a chip you can go out and buy from ARM Ltd. It's a processor design (or rather a family of processor designs) you can license from ARM Ltd, re-engineer it to suit your needs if you so choose then fabricate.

If you want a ready-to-go chip, you have to buy it from someone else who's already done that. Broadcom have done so, and it's one of their chips in the Raspberry Pi, but so have lots of other companies.

As a result, there's a whole lot of subtly different variants out there. Not all of them are 100% binary compatible with each other. I haven't been able to find out exactly which variant is used in the raspberry pi.

Re:Clue wanted

[Doc Ruby]

Sounds like the ARM platforms could use a HW API that the kernel could query on boot to know what's where. In fact that sounds like a much better architecture than x86 + "self describing HW" + BIOS - just the "self describing HW" that the kernel reads instead of using a BIOS.

Re:Clue wanted

[Anonymous Coward]

The story for Raspberry Pi is twofold: On the one hand, broadcom are not actively working with the upstream Linux community and everyone runs a forked kernel that is quite different from upstream, so this is not helpful. On the other hand, Stephen Warren (the Tegra maintainer from NVIDIA, but on his own time) just contributed the start of a port to the raspi upstream that will definitely be included in multiplatform in 3.8, and there will soon be patches on top of 3.7 that might get merged into Debian and Fedora. No GPU support though.

For the omap platform, which includes both Beagle and Panda along with a lot of other systems, a lot of work is going into making it work with multiplatform, but it's a lot harder, mostly because of the amount of code that needs to be touched. All fundamental issues have been solved by Linaro though, so 3.8 might be in reach. If not, it will be in 3.9.

To translate the platform names into something more useful:

highbank: Calxeda's quad-core server platform, used by HP and others
mvebu: Marvell's Armada XP quad-core server platform, used by Dell and others
vexpress: ARM's reference design, used for KVM and Xen guests
socfpga: Altera's FPGA platform, not too important
picoxcell: Wireless base station processors from picochip. Nevermind.

Also in 3.8, we should gain multiplatform support for Freescale i.MX (if that doesn't make it into 3.7 last minute) and ST-Ericsson's NovaThor (u8500) processor that is used in a number of Android phones. Samsung Exynos and Qualcomm MSM will take a lot longer probably.

Re:Clue wanted

[Kurlon]

A big chunk of achieving a multi-soc supporting linux kernel has been converting arm drivers to use Device Tree for initialization. You build a generic kernel, and uboot either loads a DT or supplies it directly to tell the kernel what hardware layout is present.

Re:Clue wanted

[Anonymous Coward]

GPU support won't be there any time soon, thoug it's nice to see some activity on that front. As a nice turn of events, the platform maintainer is actually working for NVIDIA, not for Broadcom. Shows you who is open source friendly and who isn't these days.

Re:Clue wanted

[ChunderDownunder]

Today I can plug my USB hard disk (salvaged from a laptop) into pretty much any PC made in the last decade and have it boot 32bit Linux.

Provided each device supports a chained bootloader to boot off USB, today's announcement paves the way for similar for ARM hardware e.g. BeagleBoard/RPi/Galaxy Nexus etc.

Another application would be rescue disks - boot from an SD card from any Android device (supporting booting off SD)

Re:Clue wanted

[drinkypoo]

As a result, there's a whole lot of subtly different variants out there. Not all of them are 100% binary compatible with each other. I haven't been able to find out exactly which variant is used in the raspberry pi.

FTFF, The SoC is a Broadcom BCM2835. This contains an ARM1176JZFS, with floating point, running at 700Mhz, and a Videocore 4 GPU. (links mine)

Re:Clue wanted

[petermgreen]

I'm guessing they did the simple and therefore relatively easy (but unfortunately not hugely useful because the complex ones are what most people use) platforms first.

So in other words for most users this doesn't mean much YET but now the framework is in-place hopefully other platforms will follow and in the future linux distros will be able to ship one kernel for most popular arm devices. Having said that it depends critically on getting the drivers to actually make those platoforms work properly merged into the upstream kernel as well.

Also the Pi is a bit of a weird case since it's armv6+vfpv2, this means that those wanting good performance on the Pi will likely have to stick with distros where the whole distro (not just the kernel) is compiled with the the Pi in particular in mind since afaict most regular hardfloat distros have picked armv7-a+vfpv3_d16 as their minimum CPU target. There don't seem to be many other armv6 devices that are popular in the hobbyist community (the only armv6 devices i'm personally aware of are the Pi, the via APC and some low end smartphones).

Re:Clue wanted

[bzipitidoo]

I bought a BeagleBoard xM. I have not been able to get much use out of it. When I had the thing working, it was quite slow, and its graphics were relatively low res. Mostly though, I've struggled with the 8G Micro SD card I got for it. The card works just well enough to boot an Ubuntu ARM installation, most of the time, but not to use it for long before some data error causes a crash.

Maybe I got a bum SD card. But this experience has me thinking that SD cards aren't good enough to replace the classic spinning hard drive.

Re:Clue wanted

[amorsen]

As a nice turn of events, the platform maintainer is actually working for NVIDIA, not for Broadcom. Shows you who is open source friendly and who isn't these days.

That actually seems to be a bit of a trend -- nVidia engineers doing spare time open source work on non-nVidia platforms. It ensures that they cannot be accused of leaking nVidia secrets in the code.

Whether it shows anything about who is open source friendly, and what exactly it shows, is less clear to me...

Re:Clue wanted

[Anonymous Coward]

That already exists, and is known as Device Tree support. It's an extension to/simplification of the OpenFirmware standard (which is basically the IEEE-approved version of Sun's OpenBoot).

Re:Clue wanted

[jimicus]

Yeah, I got that far. I just couldn't figure out whether that made it a highbank, a vexpress, a mvebu, a picoxcell or something else entirely.

Re:Clue wanted

[drinkypoo]

What this whole experience has taught me is AVOID BROADCOM, because they are going to hold onto every line of code and every driver until the end, and if you're not buying a million units fuck you.

Re:Clue wanted

[jimicus]

That's pretty endemic in the embedded industry.

It's amazing how terrible support in the mainline Linux kernel is for ADSL chips and PPPoA when you consider that the great majority of ADSL routers on the market today run Linux.

Re:Clue wanted

[Anonymous Coward]

MS is requiring PCI lookup for their RT variant of Windows 8, but that one will be bootlocked to Windows only...

Re:Clue wanted

[Anonymous Coward]

To be fair, the Freedreno (open-source Qualcomm Adreno GPU driver) developer works for TI. They can't legally (or at least within the terms of their employment) work on open code for their own chips, so instead they spend their free time working on other companies' chips.

Re:Clue wanted

[Doc Ruby]

That is how a product dies: laden with lockin, leveraging only the installed base instead of more interoperation. Meanwhile ARM and Android/Linux is installed on over 500 million mobile devices (plus a lot of servers and workstations), rapidly outgrowing the 900 million Windows installs (plus a pitiful few phones), to say nothing of the even worse loss by MS in embedded devices.

If MS could turn the lockin to lockout of upgrade with Android or Linux, it might keep another tentacle attached, but it all starts to look like the changing of the mainframe guard that MS rode to victory for so long.

Linus flaming gets job done

[amorsen]

It happened again, Linus flaming people gets stuff done.

It all started a year and a half ago with this innocent-sounding topic: [GIT PULL] omap changes for v2.6.39 merge window.

Of course it helped that most of the developers in the ARM community seemed to agree with the point Linus made. Other concerns had just taken priority.

Unified platform?

[Anonymous Coward]

If I understand correctly, the problem has been that there is no common and open standard for ARM platforms, so each chip has its own hardcoded pins and addresses that the kernel must include.

Is there any progress on an open specification that SoC designers can implement to get out-of-the-box kernel support?

Re:Unified platform?

[Anonymous Coward]

It's called device tree (DT).

Re:Unified platform?

[dgatwood]

For devices that lack a proper device tree, that's what a config file is for. None of that should be hard-coded into the kernel binary or the source.

Re:Unified platform?

[Anonymous Coward]

Every phone manufacturer does not create its own radio circuits from scratch. Same with GPU cores, memory devices, etc. Those are licensed from others. Their arrangement on a given SoC varies among manufacturers, but there is much in common and no reason, other than effort, the software drivers can't be made into loadable and configurable modules.

Linux ARM developers are making the common drivers into dynamically loadable modules so they can be loaded and configured at boot just like a traditional x86 kernel. An ARM SoC is not conceptually different than a PC full of peripherals. It just happens that ARM SoCs have the devices physically integrated into the SoC package.

As for the need for a specification; ARM already specifies how devices appear in the address space and how interrupts and other resources are used by devices. That should be all the specification needed.

Re:Unified platform?

[Anonymous Coward]

The one described here?

That looks like a way to cope with the problem, not like a solution.

You still need to make a chip specific Device Tree description and pass it to the kernel at boot, as opposed to e.g. PC clones, where you can boot any stock Linux kernel that has the right drivers.

Re:Unified platform?

[tlhIngan]

If I understand correctly, the problem has been that there is no common and open standard for ARM platforms, so each chip has its own hardcoded pins and addresses that the kernel must include.

Well, ARM is just the processor core. An ARM SoC consists of the core plus more useful peripherals, like a memory controller (so you can have well, memory), serial ports, USB controllers, display controllers, etc.

Thing is, these things exist all over the memory map - put wherever the IC designers felt they should go.

It's nice to consolidate, but I can't see how far they can go - because stuff like main memory can exist at many different locations in the memory map.

Unlike say, the x86, whose basic platform design remains unchanged since the 80s. Sure chips have consolidated and such, but they all boot the same way - you can expect the BIOS in the same spot, memory to be somewhere else (with a gap), the PCI controller is at the same location, basic VGA video, etc.

Re:Unified platform?

[Anonymous Coward]

It's the first step to the solution, moving the static hardware description from being hardcoded into the kernel into a file provided by the bootloader.

The second step will include UEFI and ACPI support for arm SoCs (probably common for arm64/ aarch), which will allow to query some of these settings dynamically from the hardware itself.

Re:Unified platform?

[MightyMartian]

A Device Tree description is a helluva easier to roll out than a newly compiled kernel for every device. I agree it's not ideal, but the ARM ecosystem is a bloody complicated one, and it's likely the best we can expect until that little piece of the Wild West is tamed. And maybe it never will be, as the attraction of ARM is precisely in its non-one-size-fits-all way of doing things.

If I'm looking at porting my kernel and software stack to some new ARM device, I'll take some comfort in the fact that the bulk of getting it running will be a spec file, and not having to do a kernel configure and compile. I've wasted enough hours of my life doing that sort of thing.

Re:Unified platform?

[petermgreen]

An ARM SoC is not conceptually different than a PC full of peripherals. It just happens that ARM SoCs have the devices physically integrated into the SoC package.

The big difference is on a modernish* PC pretty much all perhierals are either

1: Of a "standard" type and in well-known "standard" locations in the IO or memory address space
2: On a bus that looks to software like PCI
3: On some other discoverable bus or interface behind a controller that sits on a bus that looks to software like PCI

So In a PC you know where some stuff is from the start and you find the rest by enumerating the PCI bus(es) thorough the PCI configuration space (which is accessed through a well known location in the IO address space). Then in turn enumerating any buses or interfaces you find controllers for on the PCI bus.

While afaict on most arm systems there are no such enumeration features and even if there were (a few arm devices DO have PCI) there is no standard on how to access them. So the infromation has to be provided to the kernel by other methods. Traditionally it was just built into the kernel but this has made it very difficult for general purpose linux distros to properly support arm. So there has been a push to providing it externally from the bootloader "device tree" and thus moving towards a world where arm kernels are no longer device specific.

* Basically any PC that doesn't have ISA cards in it.

How About ARM/FPGA Zedboard?

[Doc Ruby]

Once they unify ARM kernels, the Zedboard PC featuring the Xilinx Zynq ARM/FPGA CPU should see even more and better development.

I'd love to see some porting of kernel functions into the FPGA, custom instructions that the kernel could execute in a flash rather than churn ARM cycles through. Is there a list of kernel bottlenecks that could be candidates for that kind of acceleration?

Re:How About ARM/FPGA Zedboard?

[Anonymous Coward]

The Zynq platform will be relatively easy to add to this list, it already does everything necessary for multiplatform, except using the common clock distribution framework, but the hardware also doesn't do a lot of clock management. Note however that the kernel you get from Xilinx has a lot of patches that are not even part of the mainline kernel, so if you rely on any of their patches, things look a lot worse.

Re:How About ARM/FPGA Zedboard?

[Doc Ruby]

I was actually thinking of using the Xillinux (customized Ubuntu) distro on the Zedboard, since the one bundled with the Zedboard doesn't seem to support a VGA console out of the box, but Xillinux seems to. But I want to keep up with the mainstream kernel updates, not some Xillinux/Zedboard/Xilinx backwater. If one of these distros that include APIs to the FPGA included the mainstream 3.7 kernel, maybe only the userland would depend on upgrades from these third parties.

Re:How About ARM/FPGA Zedboard?

[Anonymous Coward]

It would be nice, but I wouldn't hold my breath. Hopefully the multiplatform kernel can guide Xilinx in the right direction, but their kenrel team is very small and the company too often concentrates on paying customers rather than open source groundwork.

Re:How About ARM/FPGA Zedboard?

[Doc Ruby]

Xillinux and other distros seem to work on the Zedboard (perhaps better than Xilinx's). I'd think they'd rather use the mainstream kernel, with the Xilinx patches for the FPGA HW. I'll ask Xillybus.

More like PowerPC

[LordNimon]

enabling the new kernel to not only target multiple platforms but also be more in line with its x86 counterpart

It would be more accurate to say that is more in line with its PowerPC counterpart, since device tree support is the primary reason why multi-platform works on ARM today, and that support was ported from PowerPC last year. Very few x86 platforms use device trees, but they have been pervasive on PowerPC for over five years now.

Re:More like PowerPC

[Anonymous Coward]

Yes, so now the entire ARM world can experience the pain and futility experienced by the PowerPC world when confronted with the of_* "api"..

Good for Mr. T.!

[Anonymous Coward]

I like his approach - just like I admire Theo De Raadt of BSD fame -> http://linux.slashdot.org/comments.pl?sid=3007641&cid=40785151

* Since in today's B.S. "Politically Correct World", it takes courage to SPEAK YOUR MIND, plainly & truthfully (not "mincing words") - call a spade, a spade.

(It is apparently VERY effective... I saw what Mr. T. did vs. NVidia & they ended up doing the right thing so far, @ least afaik, for drivers on Linux!)...

Now, there's nothing WRONG with being polite, but... you do NOT have to a "politician" (not that well liked or respected, face it, many times) to do so. The world's TOO FULL of that... imo @ least.

APK

P.S.=> I'd shake the guy's hand actually... yes, everyone here KNOWS I am like "the poster boy" for being a Microsoft fan, but... since I 1st tried Linux in 1994 (Slackware 1.02), then Redhat 6.x (1998 iirc), & KUbuntu for ALL OF SUMMER 2010 (on a laptop while I was touring europe)?

It's grown more than Windows has (then again, it had more "room" to grow too, to catch up!)... & when MS "pulled" support for other CPU architectures (even though Intel/AMD really IS the most used overall CPU computing platform there is on personal computers, bar-none (not counting smartphones/cellphones))?

The "penguins" did THE RIGHT THING - & seized an opportunity to put their OS onto a LOT MORE than just PC's &/or Servers... &, it's showing!

(Heck - when I saw ANDROID giving Apple's iOS a "Run for its money"? I was impressed!)

One day, I just *may* become a Linux user, permanently (depends on what happens with Windows 8, & when I can no longer use Windows 7, or rather, have it be supported)...

... apk

Re:Good for Mr. T.!

[Anonymous Coward]

One day, I just *may* become a Linux user, permanently

Please, don't. We don't need you.

Re:Good for Mr. T.!

[neokushan]

Your 0.2% (or whatever it is) desktop marketshare says otherwise.

Re:Good for Mr. T.!

[Lennie]

Between 1% and 2% is generally what people think it is if they look at all the statistics.

Re:Good for Mr. T.!

[Anonymous Coward]

1. AC was most certainly talking about not wanting APK specifically. Not the whole world.

2. How is marketshare even remotely relevant ? Linux is not a company that needs to grow by any mean. So Linux doesn't *need* new users. It doesn't mean they're not welcome to join (need != want, remember). Except for the fact that current users aren't immortal and will have to be replaced someday, obviously. That is if we don't want Linux to die from a *lack* of users. It won't die from a low desktop marketshare.

Re:Good for Mr. T.!

[Anonymous Coward]

Assuming your numbers are correct and not his (I believe the assumption is correct), that detracts from his point how, exactly?

Multiple arms...

[wbr1]

If kernel 3.7 supports multiple arms, does this finally give me the codec to watch japanese tentacle porn?

Re:Multiple arms...

[JoeCommodore]

I, for one, welcome our new multiple armed platform overlords.

Here is a thought

[sgt scrub]

Does this mean Linus believes Linux on ARM isn't going to be crippled by UFEI?

Re:Here is a thought

[Jello B.]

You might be surprised to know that the Linux kernel runs on most smartphones.

Re:Here is a thought

[gl4ss]

linux is running on more arm devices than on x86.

so, no, uefi isn't going to cripple arm usage for companies.

Cool! M68k had this since...

[geert]

... a year starting with 199...

(except for Sun-3, which uses a completely different MMU).

Probably stupid question

[flakron]

Sorry for my very stupid question Does this mean, that in theory we would be able to have two different architecture CPU-s, ARM and x86 and be able to use both of them at the same time within the kernel?

Re:Probably stupid question

[neokushan]

When you say "both at the same time", I'm not really sure what you're asking. It is my understanding (note that I'm not a Linux guru by any count) that this will primarily make porting the kernel to ARM platforms a lot easier for developers (currently most ARM kernels are forked from the mainline linux branch) and, possibly, it means having to ship just one kernel for multiple ARM architectures instead of individual ones (Which should make life a lot easier for say the likes of HTC who typically have multiple smartphones on the market - each with its own kernel, eventually this means they'll be able to have one super kernel that handles them all).

Or so I think.

Re:Probably stupid question

[flakron]

Let me rephrase my question
Take for example you have a motherboard with 2 cpu-s one arm and the other would x86. Would it be possible to run applications compiled for different cpu architectures at the same time (with this change to the kernel) ?

Re:Probably stupid question

[neokushan]

...does such a motherboard exist? (Seriously, does it? Because that would be cool). ...I'm going to hazard a guess and say "no", though. Possibly different ARM chips but I doubt it'll let x86 and ARM run side-by-side...but then again, what do I know?

Re:Probably stupid question

[flakron]

I'm not aware of a such motherboard, as you said it would be cool if such a thing existed. I was just wondering.

Cheers

Re:Probably stupid question

[neokushan]

Perhaps not a motherboard, but I dare say it could be done as some sort of addin card? I don't know how that changes things, what with having to set up a "host" CPU that handles the PCI bus, then setting up the ARM CPU afterwards but....it'd still be cool!

Re:Probably stupid question

[flakron]

It would be a great add-on card, but I assume (I have no idea of engineering stuff) it would be very difficult to build one, at least at the level of usage we are talking about.
Direct access to ram, hdd etc. a parallel cpu with different architecture, but of same importance. I assume it could be used in a lot of industry fields.

Re:Probably stupid question

[connect4]

Yes it does exist, for example ThinkPad X1 Hybrid. And no, this update won't allow them to be used simultaneously, that is a separate issue that is not addressed here.

Re:Probably stupid question

[Anonymous Coward]

No. The change is about using the same Linux kernel binary (for ARM) with different ARM boards.

The analogy to x86 would be... Imagine a world where your Asus motherboard needs one kernel, and your Gigabyte motherboard needs another. That's not the way it works with PC motherboards but with ARM systems, each board is more substantially different. After this change, you can compile the kernel once and have it work on both.

From scratch...

[unixisc]

Speaking of which, anybody know whether there is a BSD from scratch? A Minix from scratch?

Re:From scratch...

[Anonymous Coward]

BSDs are full systems, not just a kernel. It may be a bit harder to build "from scratch".

Re:From scratch...

[Anonymous Coward]

I don't think BSD from scratch makes sense because the system is already built from a single tree. You can already build the whole thing with a single invocation of make, with only one source control checkout.

The reason Linux from scratch makes sense is because to assemble a distro you have to grab lots of tarballs from many sources due to the distributed development model. The BSD folks do import work from other sources but they generally work under the assumption that these projects are integrated into the tree and put under the same version control and build system.

I guess the various BSD ports trees work more like a conventional Linux distro. If you want a ports tree "from scratch" you're welcome to track down a bunch of tarballs from hundreds of sources and perhaps even script that process to basically re-create what the ports tree already does.

Re:Wake me up when...

[jones_supa]

At least in the photo there seems to be a working platform for LEG.

Sorry, but... YES, you do!

[Anonymous Coward]

You "penguins" need as many people as you can get (especially those that code).

* However, rest assured, that as far as myself? Today, is NOT that day...

APK

P.S.=> As long as Windows 7 is supported, I'll be sticking primarily to Windows - So, your "well-wishing"/"welcoming" me? Unnecessary (for now)...

... apk

Re:Sorry, but... YES, you do!

[Anonymous Coward]

You "penguins" need as many people as you can get

why ? if the point was about users, linux is not a company, it doesn't need more users. linux doesn't need you (nor me) as an user.

now if the point is about developers, then yes the kernel guys could certainly do with more of them (but only excellent people).

but you were not proposing yourself as a kernel developer, were you ? I mean, becoming a linux kernel developer is not just about saying "Hi guys I'm switching to linux, I'm a noob here but from now on consider me as one of yours !" so his point stands: linux doesn't need you.

(especially those that code).

i.e. not you, his point exactly.

I really meant as a plain user actually

[Anonymous Coward]

I'd probably be into just making apps for usermode/ring 3/rpl 3 actually - tools users actually use. That's what I've done "on the side" in both freeware &/or shareware over time in the "Windows World" since 1994 anyhow (ontop of professional programming duties).

* Who knows... but, I was actually MORE about just becoming an 'everyday user' (literally using Linux everyday vs. Windows) of Linux, actually!

It's gotten to the point of being pretty decent (I really *liked* KUbuntu 10.x).

I setup my former roommate with KUbuntu 12.x a few months back - he used it for 1-2 months, but went back to Windows (he's just a guy, not a "super-geek", on computers).

I asked him why!

He said it was decent enough, BUT, he was used to doing things a certain way, with certain tools, that he was not able to FIND in Linux (I didn't get specifics, but, I should have to 'turn him on' to alternates/analogs in the Linux world in the way of apps, that do the same thing!).

Honestly?

I think that THAT (what my old roomie said above) is what happens a lot of the time when folks try Linux (it did me in my Slackware 1994 - RedHat 1999 tries in fact, iirc).

There are a LOT MORE APPS now though, & of higher quality than in the past on Linux... it's just that I don't KNOW them all!

(Heck - I don't know "all the apps" out there for Windows either! A lot more folks, for instance, are coders now imo, than there were in the past, & they are doing freewares/sharewares like mad - that much I can state, since I was "into that game" for many a year (1994-2004)).

Same's true for Linux I think - there's more out there & of better quality than in the past, due to application level (usermode) app makers too, not just kernel devs!

APK

P.S.=> Could I do kernel level development? Sure, why not! Programming IS PROGRAMMING, and after all: That's just another ring of access for the most part after all (would just take a LOT of study first due to interdependencies) - & the compilers are still just compilers using the same languages (most likely C or C++ in the case of kernel devs though with an SDK of somekind I'd imagine)...

... apk

Re:I really meant as a plain user actually

[Anonymous Coward]

Honestly?

I think that THAT (what my old roomie said above) is what happens a lot of the time when folks try Linux (it did me in my Slackware 1994 - RedHat 1999 tries in fact, iirc).

I agree. happened to me the first time I tried ca. 1999. But now ? it's just better than anything else for my needs.

P.S.=> Could I do kernel level development? Sure, why not! Programming IS PROGRAMMING, and after all: That's just another ring of access for the most part after all (would just take a LOT of study first due to interdependencies) - & the compilers are still just compilers using the same languages (most likely C or C++ in the case of kernel devs though with an SDK of somekind I'd imagine)...

it's mainly C and assembler. don't get Linus started on C++ in kernel. ever.

also, no, there is not really an SDK, at least not in the usual sense of it. a quite common starting point to get into kernel dev is to start there: http://lwn.net/Kernel/LDD3/ (note that although it's getting outdated it's still very relevant). i.e. developping drivers and other modules is the first step. once you master it all then you can dive a bit more deeply into the kernel.

Still, I'd stick to "usermode" stuff... apk

[Anonymous Coward]

Well, I've done driver work (via the Windows DDK), & it wasn't some "huge hurdle" really!

Fact is, I found that MOST drivers are usually a LOT tinier than larger systems are in moving parts AND lines of code involved, plus, there are templates (in the Windows world @ least).

On "larger systems"? Think information systems (this is my "steady-eddy"work for livelyhood typically since nobody does their books or data EXACTLY the same, there's always room for growth in this type of coding) that I've written over time too!

E.G. -> I worked on a RamDrive driver, based off the MS-DDK template (most, if not ALL, are), in the distant past (1997). Worked out OK too!

* Still - per my subject-line above: I'd be more interested in developing what PEOPLE ACTUALLY USE though, in usermode/ring 3/rpl 3 programs, since that's what I'm used to building for, oh, 18++ yrs. now, professionally...

If Linux needs anything, it's apps & per the discussion you & I just had, in what happened to my roommate & his experience with Linux vs. Windows

"I agree. happened to me the first time I tried ca. 1999. But now ? it's just better than anything else for my needs." - by Anonymous Coward on Sunday October 07, @09:53AM (#41576315)

The Linux kernel's solid (no bugs in 3.3x really -> http://secunia.com/advisories/product/40716/ )

Well, some show here later -> http://web.nvd.nist.gov/view/vuln/search-results?query=Linux+Kernel&search_type=all&cves=on though, but they get fixed quickly enough, usually.

So, for the MOST PART, it's getting very "solid" @ the kernel level... At least as far as bug-tracking & fixes!

Also, from what I heard tell: Mr. Torvalds is VERY interested in bug fixes @ that level, & doesn't delay on fixes... he wants them FIXED AS FAST AS POSSIBLE!

(This is most unlike MS' once a month "Patch Tuesday"... but, then again, you've got to WAIT usually to get those updated kernels in Linux distros too - that is, unless you want to compile & build your OWN kernel update, which is something nice Linux offers also, that Windows doesn't!)

APK

P.S.=>

"it's mainly C and assembler. don't get Linus started on C++ in kernel. ever." - by Anonymous Coward on Sunday October 07, @09:53AM (#41576315)

Assembly &/or C were the 1st two languages I ever learned (well, after BASIC, way, Way, WAY back circa 1982 while in highschool timesharing from a DEC PDP-11 iirc over bootjack modems, lol) in 1994, when I went back for MORE strict CSC degree work (90 hours into the 120 for the B.S., have the AAS work done, long ago - just "chipping away" @ the Bachelors over time, when I have time + can afford it too, of course... lol!)

So - trust me, lol - I never "forgot" them!

However - I don't care to do asm work unless I am in a "jam" for performance (that's in usermode/ring 3/rpl 3 though), since it is a lot more work, & I am not "the greatest" @ it (too many years of NOT using it regularly)...

Still, you step-trace it, look @ data contents in variables, & off you go - nothing different than doing what you do in higher-level langauges (HLL)...

Funniest part on C vs. C++ for me:

I learned C first, & immediately afterwards, took C++ - I found it CONFUSING AS HELL, since the syntax of C can be used in most C++ compilers (think scanf vs. cin/cout), but it was more how you THINK about & CONSTRUCT programs in them that "threw me" for awhile, lol, & if you've been there? You know EXACTLY what I mean!

In fact, I'd tell anyone, especially nowadays? Take C or C++ but not both, or, @ least not in the order I did, lol...

... apk