Linux Gains Native RTOS Emulation Layer

nerdyH writes to tell us that the Xenomai/SOLO project is attempting to deliver VxWorks and other RTOS emulation for any Linux kernel. "Some weeks ago, I started laying the groundwork for porting the Xenomai emulators natively over the PREEMPT_RT kernel. Unlike the co-kernel based Xenomai version, SOLO does not require any kernel support from additional modules or patches. It is fully based on the standard POSIX library, and runs as a regular process controlled by a single image Linux kernel. As a first step, a VxWorks emulator has just been rebuilt over this new framework."

Comments

pr0n frist?

[Anonymous Coward]

srsly now.

Realtime, VxWorks, Dolla Dolla Bill Yall

[Epistax]

The benchmarks that are really expected by real time in my area are things like consistency. For example if we set a task/thread to execute every 125 milliseconds, the closer it hits the mark the better. Time lag in either direction puts that OS in the "No" category. Another important asset of an RTOS is well defined task preemption: No task gets preempted by one with worse priority. Time slicing might be enabled so that a task gets preempted by one of the same priority, and better priority tasks always preempt if they are ready to go. Also if a high priority task is waiting on a resource owned by a low priority task, that low priority task gets an elevated priority equal to the high priority task. As a last ditch effort to provide mutual exclusion / data protection, threads/tasks need to be able to disable system interrupts. Remember kids, in the RTOS world one task can take down the whole system.

VxWorks is the only OS I've played with so far that allows this, but I'm VERY curious to see what people can inject into the Linux kernel. VxWorks is.. shall we say... NOT CHEAP. And inter-version migration is a pain... and god help you if you aren't using off the shelf hardware...

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[JohnFluxx]

> Another important asset of an RTOS is well defined task preemption: No task gets preempted by one with worse priority. Time slicing might be enabled so that a task gets preempted by one of the same priority, and better priority tasks always preempt if they are ready to go.

Any normal distro Linux kernel can do this particular part. Just set the scheduler to round robin. (You can do this in KDE4 btw. Press ctrl-esc to bring up the task manager, right click a process, change priority, and chose round robin.)

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[pla]

VxWorks is.. shall we say... NOT CHEAP.

Have you ever actually had to code for Vx?

You couldn't pay me enough (literally - I've turned down jobs that wanted me to work with it... I should probably take it off my resume) to deal with that POS (by which I don't mean "Point Of Sale") on a regular basis.

Actually, in fairness, as an OS, it doesn't suck too much. But the build tools... Let's just say WindRiver clearly subscribes to the "firmware should hurt" coding paradigm. The IDE made OutLook look stable and friendly, the command line build tools simply didn't work (literally - WR couldn't even have tested them, because they failed phenomenally even on a clean install and a "hello world" module), the revision control had no objection to overwriting parent revisions without forcing a new fork... Ugh. I'll probably have nightmares tonight just from thinking about it.

Oddly enough, it surprises me to see it still talked about. When I suffered with it nearly a decade ago, it looked like a near-certainty that Linux would tap that last nail in its coffin. How ironic, that Linux should now give it new life via emulation.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[Not Invented Here]

The problem with VxWorks is that the scheduling accuracy is its only positive feature. Device drivers are rare and expensive, probably because it doesn't have a sensible hardware abstraction layer like Linux, Windows (NT family), and QNX. If you want to use the MMU on the processor you get charged again, and you get even more incompatibilities. The documentation doesn't go into much depth, and Google isn't very helpful, as hardly anybody talks about it on the Internet.

Have you tried QNX or RTEMS? I don't have any data on their scheduling accuracy, but they claim to support the same real-time features. I've also found the QNX documentation much easier to follow, and I managed to turn out a BSP and a custom device driver within a week of first receiving the software.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[faragon]

VxWorks is the only OS I've played with so far that allows this (...)

May be you need to play more :-) . LynxOS is a full-fledged POSIX RTOS, with memory protection, far better than VxWorks if disk and network is involved (I was developing toll systems real time applications for 4 years). I hope someday Linux reach RTOS habilities without having to use "cokernels", as although I'm pretty happy with current kernel preemptiveness, I would love to get true RTOS Linux (echo 1 > /proc/rtos).

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[Epistax]

Oh yes I've coded for it. I'm on my second BSP and my third kernel. It's not as bad as it used to be in some respects. The Eclipse is the IDE now. The documentation is still horrendous though. WindRiver is working hard on their own RTOS Linux solution. I don't know if they are planning on eventually digging a hole and throwing VxWorks in it, or just trying to combat the free RTOS Linux market with something they can sell to managers.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[K. S. Kyosuke]

VxWorks is the only OS I've played with so far that allows this

and god help you if you aren't using off the shelf hardware

Well, and what does happen if you do use off-the-shelf hardware? I am not exactly "well educated" in this area, but I am not quite sure whether the current typical OTS hardware is suitable for RTOS at all. Well, maybe some soft real time apps may run just fine...but I once spoke after-hours with Vojtech Pavlik (of the linux-joystick-drivers-and-other-input-devices fame) and he introduced me to the wonders of the System Management Mode, a wonderful creation of Intel capable of destroying any precise timing in ordinary PC hardware that just cannot be overridden by any normal means. Does industrial hardware that does not exhibit such features and is designed for RTOS and time-sensitive applications still qualify for the designation "off-the-shelf"?

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[Epistax]

I haven't had any experience with other systems yet really. VxWorks did add an abstraction layer for hardware drivers called "VxBus". So far the only advantage I've found is that.. Okay well I haven't found one but I did eventually get it to work. The advantage is they didn't break everything when they introduced it.

I don't understand why WindRiver hates documentation to much. They actually have a policy of not sending hard copies of their manuals anymore. Their man pages are kind of half-assed. I usually have to go straight to the kernel source tree to figure out what a function really does. I really must still state, it's a real pain to use, but their stuff DOES work. Once you get it set up right, I've found 99.99% of what goes wrong is application code's fault.

I've learned that if it takes more than a day to figure out how a specific something works, I pass it along as a service request to them. It's not my fault if the didn't document well enough!

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[Epistax]

Well, you can change to see if there is processor time being stolen from the OS by toggling a pin on a fast cycle and watching it with an oscilloscope, or perhaps polling the internal pentium timer. Someone before me had checked with our specific setup to see if this was happening (specifically we were concerned if USB hookups caused the BIOS to inject work) but nothing was detected. We use custom PC boards that could have had it disabled at the BIOS level, but I'm just not sure,

Off-the-shelf is where BSP's and drivers come in. The BSP (board support package) needs to be configured for the specific board. WindRiver provides a kajillion default packages, and if you use a off-the-shelf-board, the BSP and driver set should require little or no modification at all so you can just go straight to customizing your OS. The more customized your board is, the more you might have to do, such as writing VME, clock, PCI, or Ethernet drivers, do custom memory management, etc. I guess it's not fair to peg this complication on WindRiver. I haven't tried a Linux kernel on a custom board, but just as much configuring must go on at some point.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[spaanoft]

Have you tried QNX? I've found it really nice to use, though you still have to pay for commercial stuff. I've never worked with vxWorks but I've heard it's awful to work with in comparison.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[rucs_hack]

You couldn't pay me enough (literally - I've turned down jobs that wanted me to work with it... I should probably take it off my resume) to deal with that POS (by which I don't mean "Point Of Sale") on a regular basis.

Really? I guess vxWorks is an acquired taste then, because I'd be extremely happy to be given the opportunity to use vxWorks again.

I would have liked to have my own copy, but since a single licence for vxWorks costs more then I can reasonably afford (well, it used to, I can't find the price now), its out of the question.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[uwog]

RTLinuxFree does this. The default scheduler is kinda lame (at least last time I hacked on it), but you can for example replace them with my DMI and EDFI schedulers to get all the fancy features you describe, and more.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[joelsherrill]

RTEMS is a free, open source alternative to VxWorks that provides POSIX threads in addition to an API we call the "Classic API" that was based upon an old dead proposed VITA standard from pSOS+ folks. RTEMS is single process, multi-threaded in the POSIX sense and has almost every POSIX 1003.1b features that is possible without being able to exec a new process. We use GNU tools and maintain an APT/Yum repository so GNU/Linux users have an easy situation with the tools. Check out some of the places it has been used at http://www.rtems.org/flyers.html and in the Wiki Applications page. You can get predictable tasking and algorithmic behavior while still staying in the free software world.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[faragon]

Thank you.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[Esben]

Linux with PREEMPT_RT is as predictable (but not as fast) as VxWorks in the mentioned categories, you just have to make sure that all the RT tasks have SCHED_FIFO or SCHED_RR to behave correctly. VxWorks doesn't have (or at least didn't in version 5.4-5.5 which I used to code for) SCHED_OTHER. And that is a huge drawback for VxWorks because very often you have a lot of application threads running with no hard deadlines and might fluctuate a lot in how much CPU they use (webserver and other user interfaces). In VxWorks you have to give all such tasks priority 255 and use time slicing. Otherwise one task suddenly taking a lot of CPU will starve all tasks with lower priority until it is done.

Another problem I have seen in VxWorks is the priority inheritance: It doesn't work correctly for nested locks: A low priority task takes a lock A, runs it's own code for and then it calls into say a driver and takes lock B. Now some high-priority task wants to access the same driver and tries to lock B. The first tasks is then boosted in priority and soon finishes the driver call and unlocks B. But it is not unboosted before it release A. That is a huge problem in a RTOS: Suddenly the timing of the high priority task depends on how long a low priority tasks keeps the completely irrelevant lock A. You don't get the decoupling, that the timing of a high priority tasks only depends on the tasks of equal or higher priority, which is so important in a RTOS.

Basicly, I think core of Linux with PREEMPT_RT is a better (more deterministic) RTOS than VxWorks, but slower (longer maximum latencies for especially interrupts); but all subsystems around the scheduler etc. aren't coded for RT use - i.e. it has non-deterministic code-paths and might even make blocking calls. So an RT application on Linux/PREEMPT_RT can basicly only use basic highres timers, simple serial ports and memory mapped devices. Use of the netstack, disk IO is a no-go. But then again, the same applies to VxWorks...

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[drinkypoo]

How ironic, that Linux should now give it new life via emulation.

Uh, no. Linux is going to give it a new lease on death this way. How many Windows users have been able to jump ship since Wine has actually become useful? If this delivers it will provide an upgrade path away from vxworks that allows a company to spend their time working on a port while using Linux as an interim band-aid.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[mounthood]

PLCY - Scheduling policy FIFO (F) and Round-Robin (R) are realtime scheduling policies; OTHER (O) is the normal Unix time-sharing policy. F and R processes have a realtime priority between 1 and 99. A process will run as long as there is no runnable process with higher priority. Round-Robin processes will run for the length of one time-slice, after which they are placed last in the queue of their priority. FIFO processes run until they give up their CPU time (by sleeping or blocking) or pre-empted by a process with higher priority. Only the super-user (root) may change the scheduling policy. RPRI - Realtime priority Realtime processes (FIFO and Round-Robin) have priorities between 1 and 99. A process will pre-empt any other process that has lower priority. Normal time-sharing processes (policy O) all have priority 0. Only the super-user (root) may change the realtime priority.

I like how simple and uncluttered Gnome is, but if I can learn things like that just by poking around in KDE maybe I should switch.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[Anonymous Coward]

They actually respond to your service requests? For me, they take weeks, and more often than not come up with an incorrect response.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[nahpets77]

There's also eCos:

eCos is an open source, royalty-free, real-time operating system intended for embedded applications. The highly configurable nature of eCos allows the operating system to be customised to precise application requirements, delivering the best possible run-time performance and an optimised hardware resource footprint.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[david.given]

Really? I guess vxWorks is an acquired taste then, because I'd be extremely happy to be given the opportunity to use vxWorks again.

The last time I had to use it --- which, admittedly, was a while ago --- we had a requirement to do asynchronous I/O. VxWorks didn't support that, so we had to emulate it by using a pool of helper tasks each of which ran a blocking I/O operation. Unfortunately we had a further requirement that asynchronous I/O operations had to be cancellable, and the only way we could find of doing that was by nuking the helper task that was blocked on the I/O operation. Unpleasant, to say the least, especially as we then discovered that on the BSP we were using, half the device drivers had bugs which meant they leaked resources / crashed / made the system hideously unstable if you destroyed the task while they were in the middle of an operation...

Hopefully this has all been sorted out by now, but it still left a nasty scar. I've had much better experience with Nucleus (although it mysteriously does not have mutexes, only semaphores), and while I haven't worked with it, I really like the look of QNX.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[david.given]

Otherwise one task suddenly taking a lot of CPU will starve all tasks with lower priority until it is done.

I recently worked on a mobile phone platform (not based on VxWorks) which had a mechanism for sending messages to specific threads. There was a system wide 150-slot message queue. There was a background thread that ran at low priority that was supposed to do non-real-time things like UI work. This thread was a message receiver. The system did not support timeslicing.

Can you see the problem yet?

If the background thread didn't get enough CPU time, it wasn't able to keep up with the incoming messages that would get posted by high-priority threads. This meant the queue would fill up, and once the queue filled all the way up, the system would reboot. The end result was that since the system didn't support timeslicing, if any thread running at the 'background' priority spent too long running without yielding, the message receiver thread would get starved of CPU, and splat. They were using a low-priority background task to handle high-priority system critical operations. When we queried them on this, they said, "Well, we don't really plan task priorities; we just adjust everything on an ad-hoc basis until it works."

Gah.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[Animats]

Good points. If you're doing an embedded hard real time system, you might need the small size and timing repeatability of VXworks. If not, you don't need VXworks at all. It's much easier to write to a POSIX interface. There's not much software for VXworks you'd want to port to Linux. So a VXworks wrapper for Linux doesn't meet any widespread need. Maybe someone needed it for a specific porting job, so it was worth doing once.

I'd still like to see a real message passing system, like the one from QNX, in Linux. Even just writing web apps, Linux interprocess communication is still too lame. We have people using SOAP and JSON over sockets to do an interprocess subroutine call. I recently had to use Python pickling over pipes to a subprocess, and it's so primitive coming from QNX, where you have MsgSend/MsgRecv and a real client/server interprocess communication model.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[TheLink]

There's also Tron, which is apparently quite popular in Japan and used in lots of embedded stuff.

http://en.wikipedia.org/wiki/TRON_Project

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[HungWeiLo]

They use Eclipse as their IDE now, so it's much better.

They certainly much better than LynxOS (who also uses Eclipse as their IDE - but their plugin as not as well integrated by far)

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[MightyYar]

IIRC, QNX is intel-only. At my company we like to use whatever chip is the best deal for the power we need. In 10 or so years, we've gone through 68030, 68040, 68060(?), PowerPC, and various Intel boards - all using VxWorks.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[spaanoft]

QNX used to be intel-only, but has been ported over to other chipsets. I know I've used it on an arm and some ppc before.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[Anonymous Coward]

Yep, that interference from System Management Mode frequently throws a wrench into RTOS performance on PC.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[PCM2]

I have asked Wind River representatives whether their Linux product is meant to replace VxWorks and they emphatically said no. (If that means anything.)

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[necio_online]

I've played with the Linux realtime extensions (preempt_rt) in a production environment and so far I've had good results. This is a very simple usleep test that shows how having the patch helps: http://wiki.freaks-unidos.net/weblogs/arhuaco/preempt_rt-test You can use the SCHED_RR or the SCHED_FIFO scheduling algorithm for realtime applications.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[Anonymous Coward]

pSOS
That brings up memories.

I was there when WindRiver bought it. I made a fork that changed it to not use recursive make (see http://www.xs4all.nl/~evbergen/nonrecursive-make.html) however because no-one there was considered head honcho of that source tree it didn't get incorporated. I talked to another engineer and the same thing had happened to him. After that I realized that no matter what platitudes the PR folks were saying, they really had just bought it to kill it off. That, combined with the "Linux is the devil" attitude from management caused some serious disillusionment about the company. After I left I heard that management did an about face on the Linux front.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[jmason]

fwiw, I ported some QNX code to Linux a few years back, and wrote my own version of MsgSend()/MsgRecv() in a single .c file using UNIX-domain sockets. it's extremely simple, as long as you adopt the same limitations on portability (ie. writing raw C structs to the wire), lack of network support, and concurrency as the QNX message-passing has.

QNX message-passing is nothing that can't be easily rewritten.

Re:Realtime, VxWorks, Dolla Dolla Bill Yall

[Kilroy]

The command line build tools are now headless Eclipse, which is eyegougingly frustrating. I just spend days trying to figure out why it was randomly giving Java Null Pointer exceptions while trying to do imports through the automated build system, but it won't fail while I'm running it manually or with debug tools attached. Flaming. Pile. Of. Poo.

I can't wait to replace it with Linux, at least when that fails to compile code, it will probably do so every time and in the same place. Having the build system just run make a few times in a row so it might finish does not make me glow with joy.

Re:A quick search reveals

[Anonymous Coward]

don't click that link, mod parent down.

Re:A quick search reveals

[Tony Hoyle]

FFS don't click that link - it's some sort of browser spawner/malware/virus.

I had to power cycle my machine to shut it down as it managed to completely saturate the machine.
As far as I can tell it:

1. Tried to log me onto a gay porn site
2. Tried to open up IRC and do something (failed, luckily, since osx won't let such things happen automatically.. my screen just filled boxes asking if I wanted to start colloquy)
3. Tried to run a .exe - luckily on my mac that did nothing.. that's the virus payload I guess

I reckon if you clicked that button on a windows machine you'd be crying right now - and your passwords would be all over IRC too...

Re:A quick search reveals

[Aldenissin]

So you are saying that the linuxdevices.com website is compromised?

Re:A quick search reveals

[ezzthetic]

I think it's referring to the link in one of the replies.

Re:A quick search reveals

[Teun]

No, it's Lord Haw Haw's Yahoo link that's attacking windows machines.
But then, who in is right mind would admit on /. to running such a thing :)

What is the relationship with Xenomai?

[Anonymous Coward]

IIRC, the main goal of Xenomai was to provide a co-kernel approach (a RT kernel runs the RT tasks and the lower priority task is the Linux kernel). Now this Xenomai/SOLO seems something completely different: just a conversion layer between the VxWorks API and the POSIX RT API. If by chance you are running this layer on a kernel which has good RT properties (for instance Linux PREEMPT_RT) then it will behave more or less like VxWorks (and in addition you can run normal Linux app next to it). I wonder why they called their new things Xinomai/SOLA as it doesn't seem to have any technical relationship with Xinomai. Is it a purely commercial reason?

Anyway, so far the reason for having the co-kernel approach was that Linux was not able to provide low latency, so I guess it's good news: some knowledgeable people consider that the latest Linux version (with PREEMPT_RT) is up to the task :-)

who exactly needs this ?

[demiurg]

V2L existed forever, but nobody used it simply because this is not needed. API porting (which is the problem that this kind of emulation solves) is one of the minor problems that one faces when porting code from RTOS to Linux. Code written for RTOS usually has very different architecture from what one would recommend for Linux. Once architecture re-design is done, porting the API is easy.

Re:who exactly needs this ?

[willgps]

I guess that makes me a "nobody" then, since I have had the unfortunate pleasure of inheriting a project at work that attempts to shoehorn a vxworks project into linux via v2lin.

Given enough time, I would love to chuck v2lin out altogether and access pthreads directly.

Does anybody have any tips for surgically removing v2lin from legacy code?

Re:A quick search reveals

[Anonymous Coward]

Thanks for the warning! I almost cli... oops, I couldn't help myself. I clicked agggghhhhhhhhh!!

Re:A quick search reveals

[MMC Monster]

I clicked on it (I'm using firefox3 nightly on WinXP and was curious :-) ). It did start to do some crazy stuff on the system. I unplugged it. So far on reboot everything appears fine.

Re:A quick search reveals

[Anonymous Coward]

It's using some sort of Yahoo redirection. The actual website is: "members.on.nimp.org" Do not go there unless you have Javascript turned off or blocked (applies to Firefox, Linux, anything apparently).

This should be sent to the Firefox dev team. Maybe there is nothing that can be done but I don't think a website should be able to move the main window around on your screen like that. If I remember correctly this web page has been around in some incarnation for years so maybe they already know about it.

Re:A quick search reveals

[Midnight Thunder]

But then, who in is right mind would admit on /. to running such a thing :)

Just use the classic defence "I was reading /. from work" ;)

Re:A quick search reveals

[Anonymous Coward]

I also opened the link without thinking -- and then power cycled. After powering up again and reviewing Firefox's sessionstore.js, I believe the link leads to a URL of the form "http://members.on.nimp.org/index.php?steal=1&key=XXXXXXXXXXXXXXXX". (The X's appear to be a hexadecimal code, but I'm not sure what the meaning of the code is.) The content of that page is:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>GNAA Last Measure Live!</title>
<meta name="keywords" content="bsd digg gay gnaa internet last measure linux nigger slashdot freebsd niger internet providers internet service providers nigga gays niggers openbsd internet access cable internet xandros netbsd gai gay sex gay personals bds gaysex enternet dial up internet cable internet service lunix internets gay black men internet services cheap internet service gay chat rooms internet fax service insmod gey internet radio dial up internet access international internet gay massage inux gay movies gay com gayboy internet business internet businesses homosex internet college internet banking schwul internet gambling neger homosexuales internet poker internet filtering satellite internet connection internet roaming gay cock broadband internet access gay adoption asian gay gay bears gay guys linux on windows internet connection schwule gej maryland internet linux recovery gay sites michigan internet remote internet access making money on the internet gay pornography gay hardcore internet speed up atlanta gay internet game older gay men gay nudist gay shopping gay san francisco houston internet california internet nigga stole my bike gay houston gay marriage gay bear internet auctions internet worldwide linux laptops redhat9 internet billing broadband internet linux drivers linux pc gay amsterdam gay seattle gay bdsm selling on the internet mature gay men internet call gay sex chat internet marketing gay toys internet printing linux help freebsd ports mobile internet linux for windows linux clustering gay chat teen gay porn ny gay alabama gay freebsd 6.0 linux os spain internet clips gay hairy gay men gay leather make money on the internet gay boy gay philadelphia gay community internet via satellite freebsd 6 gay cartoons gay love nigga lyrics niger uranium internet search gay news hate niggers gay georgia oral gay sex linux downloads communication internet niger africa bds suspension gay nude boys linux applications gay pics enternet 300 internet censorship internet information server gay australia redhat linux gay niggers niger forgeries gay phoenix gay orgies internet sites aspergillus niger internet traffic oracle linux gays fucking linux support test internet internet messaging gay vivo horny gay the internets niger forgery bds marketing freebsd org sex gay movies internet canada niger yellowcake gay women linux apache the niger river freebsd wireless internet development bodybuilder gay freebsd java can a nigga get a table dance gay latinos deng gai linux penguin realest nigga real nigga roll call linux tutorial japanese gay gays in military freebsd screenshots linux systems linux software freebsd apache joseph wilson niger installing freebsd gay store freebsd update freebsd port freebsd upgrade teen gays install freebsd freebsd cvsup dead niggers cumshot gay ten little niggers gays com freebsd laptop fuck your couch nigga broke nigga internet stock trading niger document jews spics wtc jew jewish holidays jewish calendar jewish community center anti semitism single jews jewish names jewish history jewish museum jewish hospital jewish wedding bernanke jewish us jews jewish music jewish federation barnes jewish russian jews jewish jokes libby jewish jewish singles jewish religion barnes jewish hospital long island jewish jewish people jewish news jewis

Re:A quick search reveals

[Nuskrad]

You can disable certain Javascript functions in Firefox, such as the ability to move or resize windows. Options>Content>Javascript Advanced

Re:A quick search reveals

[Anonymous Coward]

Don't panic people, it's just a standard dose of the GNAA Last Measure. Not a virus or malware, just a script for freezing computers and showing tubgirl.

Re:A quick search reveals

[c0p0n]

Aye, I've reported it: https://bugzilla.mozilla.org/show_bug.cgi?id=424525

Re:A quick search reveals

[Anonymous Coward]

What's worse, the link (that Slashdot shows as a Yahoo link) is actually an only slightly obfuscated Nimp link.

Aside, I find it amazing that a 4 letter TLD is allowed to be used this way as long as it has. Nimp isn't just a shock site, it's got to break enough criminal laws to put it's owners and people that link to it in jail.

Re:A quick search reveals

[SkyDude]

According to UrbanDictionary.com

nimp.org
A shock website, by entering any text in front of on.nimp.org, you create a link to the site. ww.texthere.on.nimp.org would be a link to the site.
The site itself is merely a way to make your web browser jump around on your screen, and open all programs attached to it. It can be annoying, but it is easy to stop on Mozilla Firefox. Microsoft Internet Explorer is very vulnerable to this "attack"

x: www.porn.on.nimp.org
y: *click*
x: dumbass...

Cmdr Taco - when will you permit removal of this type of crap?

Re:POS needs realtime? hahahahhaha

[richpm]

"Why not just get a faster computer," Power consumption? Heat? Noise levels? Size? "... because if they had a clue, they would leverage Eclipse ..." I guess they've got a clue then, they've been shipping an Eclipse based IDE for 2+ years now and Wind River are /very/ active in the development of CDT. In fact the CDT project lead works for them now. Admittedly they do some stuff in a slightly non-standard way (e.g. not the way vanilla CDT does it) but that's with good reason and allows them a far more flexible build system than the standard CDT project model allows.

Re:A quick search reveals

[ozmanjusri]

Thanks for the spam sunshine.

How 'bout you reformat and reinstall so the rest of us don't pay for your "everything appears fine." system?

Re:POS needs realtime? hahahahhaha

[billcopc]

I don't think you should be speaking against RTOS without any actual RTOS experience. It just makes everyone else assume you're an ass.

These things typically run on embedded devices, not a friggin' Dell midtower. They do one job and they do it with exacting accuracy, on minified motherboards and fanless CPUs, hooked up to custom-built controllers and monitoring equipment.

RTOS tasks are typically things we used to do in solid state with simple feedback logic, but the RTOS allows it to be done in software at a lower cost, plus allowing easy updates or adjustments without a complete redesign.

Re:A quick search reveals

[Curien]

Meh... I tried it in Opera just to see what would happen. It opens a flickering pop-up (singular -- not multiple) and manages to play the "I'm looking at gay porno" through the speakers. All that was necessary to fix it was a "close window" gesture.

Oh dear god no!

[malevolentjelly]

Why would you ever need to emulate an RTOS in linux? Linux does not do what ThreadX, VxWorks, INTEGRITY, uVelocity, or any of the sort do- imagine you're an embedded device manufacturer and suddenly you need to bump your device up from 64k chip of ram to 8mb. This is completely retarded. In the embedded world, true RTOS are used for things that can never fail, lag, or be insecure in any way. Linux is generally used to fill in a cheap userland. Like on Sony TV's, the RTOS junk is handled by uVelocity, but they use linux for the OSD, etc. You DO NOT PUT LINUX in places you put VxWorks. Imagine having that ludicrous monolithic server OS in a PACE MAKER. Or a NUCLEAR MISSILE.

I could see people wanting to hypervise linux in a secure RTOS but emulate an RTOS in linux? Please tell me this is for development purposes... further still- are they completely insane?

Re:Oh dear god no!

[SanityInAnarchy]

Why would you ever need to emulate an RTOS in linux?

RTFA.

imagine you're an embedded device manufacturer and suddenly you need to bump your device up from 64k chip of ram to 8mb.

Imagine you've already got the 8 megs, and you still want things to happen in realtime. Oh, and you want to actually have drivers.

Suddenly, things like VxWorks are going to cost you in licensing fees and development time, in return for... what, exactly?

Re:Oh dear god no!

[malevolentjelly]

Linux is not realtime. "Realtime linux" is a non-linux realtime OS with a non-realtime linux compatibility layer... emulating a REAL RTOS?... Why would you emulate a realtime system in a non-realtime system? Doesn't that defeat the purpose of a realtime OS?

Do you have any idea why people use realtime systems?

With VxWorks you pay license fees... FOR A REALTIME SYSTEM. You're also able to do a lot more with a lot less resources. In the embedded world, less is more! You save millions cutting kb's (or mb's) of ram out of hardware. And this emulation layer saves what, some programmer a week or two tops porting one POSIX-compliant VxWorks application to a semi-POSIX compliant linux device. The licensing fees don't seem so bad when you think about the extra hardware necessary to use a make-believe-realtime OS like "realtime" linux.

I've got a better idea- use a real, tried, trusted RTOS and simply use an emulated UNIX layer if you need that sort of support (most decent RTOS support this). This pairing of linux and Xenomai's RTOS just sounds awkward. Software costs are just miniscule compared with the cost of making a bulky device with hardware that outclasses its functionality.

Re:Oh dear god no!

[SanityInAnarchy]

Do you have any idea why people use realtime systems?

Yeah, pretty much.

Software costs are just miniscule compared with the cost of making a bulky device with hardware that outclasses its functionality.

...aaaand it looks like you didn't read my post. Try again.

Re:Oh dear god no!

[malevolentjelly]

Imagine you've already got the 8 megs, and you still want things to happen in realtime. Oh, and you want to actually have drivers. But Linux is not realtime, so its drivers can't be realtime. Part of what makes a system realtime is the way its drivers are written. Realtime device manufacturers are generally expected to be writing their own drivers or using specifically realtime drivers for an RTOS.

The moment anything passes through a linux kernel, it's no longer realtime. At best, it's "soft realtime" aka "realtime except for when it is not". For a realtime linux system to work, you'd have to run two kernels (linux and an RTOS) with two different processors, usually on an asynchronous multi-processor device, where linux runs on a dedicated non-realtime processor and an RTOS runs on a CPU designated for realtime.

SO either Xenomai is actually emulating linux as well as VxWorks in parallel, or VxWorks is running emulated as a soft realtime layer- because the moment anything TOUCHES that linux kernel, it's no longer realtime. It must pass directly through to Xenomai's RTOS or it's not realtime. If you wanted a realtime system PLUS all the perks of linux, you just got neither. Either this is useless or it is NOT LINUX.

At best, you now have some crappy open source RTOS that communicates with linux through a socket. How convenient! There's almost no benefit to this over simply having a unix compatibility layer or a real RTOS, and hypervised linux running in parallel with a vxworks compatibility layer. VxWorks can't touch linux without defeating the purpose of having used VxWorks at all.

Re:Oh dear god no!

[Jamie Lokier]

"Realtime linux" is a non-linux realtime OS with a non-realtime linux compatibility layer... emulating a REAL RTOS?...

That was true in the past, but it is no longer true. The algorithms of the latest approaches to real-time Linux, when working together, actually do provide deterministic, hard real-time responses if the real-time parts of your application are coded appropriately. (By this, I mean that you don't expect a deterministic response when trying to use a service which isn't, such as a filesystem.) And they do this at the same time as supporting the vast set of devices and features of a general purpose OS.

Older approaches to "real-time" on Linux either had a separate real-time layer, with Linux itself as a sort of task running on top of that and extra drivers required, or they used a best-effort approach, where drivers and other code could potentially hold a lock for a long time, blocking real-time scheduling, but you hoped to minimise those through testing and tweaking drivers all over the place.

The current approaches work differently. All drivers can take locks, but tasks which require higher priority or even deterministic scheduling aren't blocked by locks, nor by other interrupts (unless those have conflicting real-time requirements too, of course), except when there is genuine contention over a common resource, such as accessing the same chip.

This is just like the Linux-over-real-RT done before, but without having to have separate interrupt infrastructure and so on.

Additionally, the current approach allows RT tasks to use system services like filesystems and networking and so on, when that's convenient. When this is used, using a non-RT service means the RT tasks take on potentially non-RT properties but only for the duration of that call, which is expected by the RT caller anyway at that point. Furthermore, Linux applies a priority inheritance technique even in that case.

The ability to intermix RT code and non-RT services well is very convenient for some applications. E.g. mobile phones have strict RT requirements for the radio, but not for the GUI. It is convenient for hardware cost and versatility if both can run on the same multi-core CPU, scheduled by a common OS.

Why would you emulate a realtime system in a non-realtime system? Doesn't that defeat the purpose of a realtime OS?

Because the underlying Linux got better real-time properties since you last looked; the "non-realtime system" is now a mixed system with some real-time capabilities when requested.

That's not at all obvious, because it's not done in a simple way.

A remarkably large number of different things need to be implemented together to get those properties while keeping close access to the general purpose OS services, and using common drivers. Things like high-res timer queues, spinlock preemption, prioritised lock acquisition including userspace locks (RT-futexes), priority inheritance, O(1) scheduling decisions, preemptible interrupts (i.e. interrupts become RT tasks themselves), and countless details.

But if you bring the right ingredients together, you can see that the code paths, although non-obvious, are able to provide deterministic real-time response to particular applications on appropriately chosen hardware, while still able to run general purpose OS services at the same time on the same hardware, and without having a lot of special drivers and code dedicated to the real-time part. And there are quite some benefits to this mixing, for more complex applications.

This stuff still isn't suitable for nukes and car engines. But it's not suitable because it's too large and complicated to prove everything is right and nothing critical breaks the rules, not because it doesn't provide RT guarantees in principle.

It is well suited to things like mobile phones, even the radio DSP part which has strict timing requirements, since it does provide suitable mechanisms in principle, and any failures in an application like that are not catastrophic but simply bugs to be fixed in the usual way.

Re:Oh dear god no!

[malevolentjelly]

Because the underlying Linux got better real-time properties since you last looked; the "non-realtime system" is now a mixed system with some real-time capabilities when requested. I see. With the understanding that this can't replace all applications where one might need an RTOS like VxWorks, I see where the VxWorks emulation could prove very helpful in porting applications to rich embedded systems like cell phones or set top boxes.

In this case, the project must be very delicate in providing vxworks support while not stepping into any of these non-RT boundaries.

Of course, I still come from the school of thought that recommends a re-write when switching from a true RTOS to a hybrid-RTOS. The emulation approach seems a little too "soft" for most of the embedded applications I am used to.

I rescind my statement about linux requiring to work in tandem with an RTOS in order to perform realtime tasks.

Re:Oh dear god no!

[Jamie Lokier]

In this case, the project must be very delicate in providing vxworks support while not stepping into any of these non-RT boundaries.

You're right, and I will be very surprised if they get this right in all corner cases. The kernel is pretty complex, and the C library's threading implementation is also very complex. I expect by themselves these will have corner cases where RT properties are not maintained, without being clearly documented. So no matter how much effort the folks writing the vxworks layer put in, they are dependent on other folks getting a lot of things right which are not precisely specified nor testable.

So in practice, I think it will be something which provides RT properties when running smoothly (e.g. (this is a guess) not doing things like initialising new RT processes or adding new devices), but you still have to test your application to get to the level of confidence that it's good enough for practical scenarios. As a tool, that puts it somewhere more reliable for RT than older soft-RT systems, but not quite to the level of guarantees from a much simpler, hand audited (we hope) system.

Mind you, I'm not sure where VxWorks fits on that spectrum either. If you really, really need hard RT assurances, wouldn't you write your own (very) tiny kernel and consider every critical code path? I have done this on a couple of occasions, for relatively simple devices.

Re:Oh dear god no!

[SanityInAnarchy]

I still don't see a hypervisor'd Linux being useless here -- or a Linux which has been modified such that certain parts of it are deterministically realtime (including drivers), and certain parts are not.

Take a task which needs to be hard realtime, but for which you'd like to see reports. The task continues to operate at hard realtime, on whatever hard realtime layer is needed, throwing log messages into a ring buffer in a realtime-compliant, deterministic way.

Another task, which doesn't need to be realtime at all, attempts to pull stuff out of the ring buffer and send it over the network to a logging machine, or to local storage, or whatever. Maybe it even generates fancy reports, flips blinkenlights, etc.

Worst case, the reporting/logging task falls behind, and generates an error -- but the hard-realtime task just keeps chugging along, and doesn't even notice.

That's probably a bit contrived, and certainly naive, but I do imagine there are other, similar cases where you need some tasks to be realtime, and some tasks can lag. And if it can be done without a hypervisor, that's probably a performance gain.

Re:POS needs realtime? hahahahhaha

[Anonymous Coward]

A RTOS isn't about speed, it is about predictability. It is about guaranteed response.

There are some things that a 200MHz machine with the right software can do quicker and more accurately than a 4GHz machine with a standard OS.

What it comes down to is they built an expensive mansion, but built it on sand. Doesn't matter how expensive or big the house is, if it is built on a poor foundation, the house will be unstable.

I have seen process control applications where an 8MHz 8086 was fine. No OS, just application coded in ROM. Fast enough, stable. When newer, faster processors came available, the bosses decided, "We have power to burn, let give the application a GUI." So now they run with dual processor motherboards. But... motherboards today are not as fully debugged as the old days. Some companies never kills the bugs, they just release a new Motherboard with a new (buggy) chipset. Same for the OS. A well written application becomes unstable.

If you drop a scratched DVD in you DVD drive, does your windows machine kind of hang while windows tried to decide what is there? I've experienced that quite a few times.

BTW, this is similar to Linus' exchange with Tannenbaum on monolithic v.s. microkernel.

Re:A quick search reveals

[WidescreenFreak]

And we're to trust an Anonymous Coward who says that malware (regardless of whether it's a hijack or an executable) from another Anonymous Coward is safe?! I don't fu*king think so!

Re:A quick search reveals

[rrohbeck]

No problem here except for the "interesting" background pic.
Firefox + Adblock + Noscript + Privoxy :)

Re:A quick search reveals

[Anonymous Coward]

Nobody targets Opera because Opera does just fine denying access itself by crashing all the time.

Re:A quick search reveals

[neumayr]

Cmdr Taco - when will you permit removal of this type of crap? Why would you want to remove it? It's part of net culture, and a (for this site's audience at least) generally harmless reminder to check where a link links to before clicking it.

Re:A quick search reveals

[neumayr]

After reading the comments further down the thread (lol) I take back the part about the generally harmless.
But there is some educational use for those links. Keep them coming, I say.

Re:POS needs realtime? hahahahhaha

[Enleth]

If you are so smart, tell me how to put a cheap 2GHz PC in a 15x10x8cm controller compartment of a robot I'm making. And power it from a 13.8V gel-lead-acid battery that needs every bit of spare power for the main motor. The specification says nothing about having a needless, integrated air heater in the controller, but any CPU that draws more than 200mA and requires more than one voltage with DC-DC convertion efficiency less than 90% is way too much.

And there are defnitely more things that really need accuracy. Basically every kind of system that interfaces with hardware on a raw I/O level, with control implemented in software. Hell, a dumb high-speed rotary-to-linear transducer with a motor needs extremely precise software control.

Looks like you need to get a broader view of things before stating completely unfounded statements in the public.

Re:A quick search reveals

[kesuki]

well, the html code is fairly clean, but since it loads a couple swf files, and avi, and numerous websites and irc, as well as im clients, there is the possibility that the swf file or avi are malformed to contain an exploit, or the websites could have exploit code on them, while connecting to im and irc can expose your ip address to hackers, and since aim and irc often have gaping security holes, that could be the vector of attack.

I'm basing this on the guy who pasted the web page code, after a reset.

it would be far more scientific to take a known clean, preferably sp3ed machine make a backup of all files in linux (dual boot with 2 hds or whatever) then diff the results after letting that site run for 1 minute. any exploits would then show up among the files that normally change, the list should be fairly short, and programs and prefetched files etc will be easy to spot.

Re:A quick search reveals

[ArcCoyote]

Classic stuff. Might own you in IE, but FF3b4 with NoScript just gave me the GNAA logo and some nasty background images. I like to live dangerously, so I tried Firefox without noscript in a VM and let it rip. Even with a bazillion popup windows, I could still get to File->Exit and quit firefox.

Oh, BTW, It does try to post the site the content of your clipboard and load a "LastCoffee" Java applet, which I'm sure is not good. Doesn't work on up to date Java.

I am not going to try this in IE, because I don't feel like dealing with the slight chance of rebuilding my VM. I doubt it could do much worse than hang IE7 (on Vista anyway.)

Re:A quick search reveals

[ArcCoyote]

Ok, so I tried it in IE7 on Vista. It can move the damn window around, which is more than it could do in firefox, but it couldn't launch any popups or apps. IE's blocked action bar pops up and stops it cold. I could close the window easily by giving something else the focus, which disables the window-controlling script, then clicking the window close button.

Re:A quick search reveals

[SkyDude]

Part of net culture? Harmless? Assuming you don't have your tongue firmly planted in your cheek, I respectfully have to take issue with your statements. Having said that, let me stipulate that my response probably does not apply to the typical /. reader.

Sorry, did I say 'typical'? I'd better be more careful....

Much like graffiti spray painted on the side of a building or vehicle, these things should be removed as quickly as possible. Deny the perp his/her "moment of glory". It serves no purpose and in other web forums, a trusting visitor just might damage their computer or have their personal identity stolen through the running of a nefarious script or download of malware. Not all users are as savvy as /. readers. As someone who provides service and support to computer users, I see the results of such vandalism every week.

Re:A quick search reveals

[krbvroc1]

I'm running NoScript Firefox extention under Linux and while my retina hurts, there was no moving screens or whatnot. By default, I do not trust javascript/activex. Get NoScript and configure it!

http://noscript.net/

Re:A quick search reveals

[neumayr]

Consider that even if such things like the original post get removed, all you're accomplishing is the simulation of world where those things don't exist. The real problem doesn't go away - it still would be possible to give people malicious URLs through other channels, who are then more likely to click them without checking them first. After all, it's generally safe to do so.
It's desensitizing, and I think that's a lot more dangerous than feeding a few absent-minded forum readers a malicious link, shaking them up a bit.

Re:A quick search reveals

[fuzzix]

Much like graffiti spray painted on the side of a building or vehicle...

Some of the graffiti I've seen is preferable to the mass of advertising billboards around the city which assail my eyes... I'd rather see goatse painted on a wall than another fucking soft drink advert - at least it would bring a smile to my face... ...that's not to say I think most graffiti is attractive - most of it is garbage (daubing your name on a wall has no meaning when no one has any idea who the fuck you are) but I don't think it detracts from the drab urban landscape I inhabit.

Re:A quick search reveals

[The End Of Days]

I'll admit it. I run Windows XP on this laptop. Don't feel like struggling with my computer to browse the web for a little while.

Re:A quick search reveals

[Teun]

Hehe, I see it the other way around.
I don't like having to fend off thousands of malwares with an OS that implemented networking as an afterthought.

Re:POS needs realtime? hahahahhaha

[tuxicle]

RTOS tasks are typically things we used to do in solid state with simple feedback logic, but the RTOS allows it to be done in software at a lower cost, plus allowing easy updates or adjustments without a complete redesign. Sounds like something I'd rather do with programmable logic instead.

Re:POS needs realtime? hahahahhaha

[Tacvek]

Honestly though, it sounds to me like CPLD's or FPGAs may be the proper solution. They are real-time by definition, running what amounts to a large number of processes in true parallel. An FPGA with a built in RISC microprocessor honestly sounds like it would be an easier and cheaper system to develop on than many RTOS's. Obviously one implements the real-time components in the FPGA, but runs the parts that are easier to code for a traditional processor on the embedded processor. That honestly sounds like a saner solution. IT also usually has minimal current draw, and generally needs only one DC voltage. My question is why is this approach so rare? It seems like far fewer people use this approach than its benefits seem to imply. Am I missing some drawback?

Re:POS needs realtime? hahahahhaha

[beguyld]

Honestly though, it sounds to me like CPLD's or FPGAs may be the proper solution. ..... My question is why is this approach so rare? It seems like far fewer people use this approach than its benefits seem to imply. Am I missing some drawback?

Depends on the application, the system functions needed, the volume it will be produced in, the time to market required, etc. FPGAs and CPLDS are certainly used a lot. It's definitely a multi-billion dollar business. But these days mostly where performance is critical, and is worth the extra cost. FPGAs are not that cheap. The main ones we use cost us $100-200 each in small volumes. For one project, we're using a high end version that costs $2500.

Think of coding for CPLDs or FPGAs as a level _below_ assembly. Why isn't more software written in assembly code these days? It takes too much time. Even more so for good FPGA code. It is only worthwhile for certain applications which really need the performance per watt. And for high volume applications, the FPGA design is just a prototype stage, and then the design is moved into an ASIC.

Also, when you do build a system with an FPGA and either an embedded CPU or your own board design, you are no longer leveraging off of the work of many others. You are starting over from the bare metal, defining your own hardware interface, timing, APIs, drivers, and everything above that. Being able to leverage off of the hundreds of man-years of programmer time in Linux is a huge benefit, if you can do it.

Also, setting up a build environment, debugging interface, and other necessary tools eats up time. Some things you can find, but it's a lot harder than buying something like a Gumstix board with Linux loaded, and a set of cross-compiling tools on a CD. But you can't always use Linux for hard real-time hardware control.

In some cases, a FPGA or CPLD is the right answer, though as I said, now you have to develop everything yourself from scratch. It can be interesting and fun, if you don't have your company's ability to pay your salary (and everyone else's) dependent on you getting it done in 2 weeks....

The system I'm working on now uses a 400 MHz XScale based board we buy off the shelf, running Linux. Then we have a couple of simple drivers to interface to an FPGA which does the low-level hardware interface. But that FPGA code took many many months, and new features take many weeks to add and get right. (if you want it to run fast that is)

For a lot of low-level hardware control, the easiest thing is to just grab an off the shelf 8-bit or 16-bit processor and write mostly C code. Add a tiny bit of assembler, if you need it, and you can get the job done much easier and faster. Often you don't really need an RTOS, or can use a very very simple one. Since you can get 8-bit processors that run at 50MHz or more, and C code is so much faster to write than FPGA code. I've done many of those designs with serial port control in the past, and these days even the small processors can handle a simple TCP/IP stack.