I'm not the AC, but I'll try to share the knowledge.

I'm a kernel programmer and worked on a Linux based realtime highdef broadcast quality H.264 video encoder that used a hybrid mix of multiple cores and FPGAs, so I'm fairly familiar with at least one use case.

openMP has uses for parallelizing workloads via pragmas in the compiler code. That is, take an app that is designed for a single CPU, add some pragmas and some openMP calls and let the compiler parallelize it. It does this [mostly] by paralleling loops that it finds.

Parallelizing [simple] loops can be done in [at least] two ways:
(1) A single loop can be parallelized across multiple cores
(2) If a function does loop A followed by loop B and loop A and B share no data, they can be done in parallel.

openMP assumes a shared memory architecture (e.g. all cores are on the same motherboard). Contrast this to MPI that can go "off board" [via a network link]. There are hybrid implementations that use both in a complementary fashion.

A good use case for this is weather prediction/simulation which is highly compute intensive but doesn't have realtime requirements. We just want our final answer ASAP, but what the program does moment-to-moment doesn't matter. Another use case is protein folding.

But, neither openMP nor MPI is well suited to a realtime situation that requires precise control over latency. Also, openMP doesn't support compare-and-swap. And, it's prone to race conditions.

Ideally, designing a given app from the ground up for parallelism is a better choice. If one does that, the fanciness of openMP isn't required. My last implementation of an openMP equivalent [that also incorporated what MPI does] was ~1000 lines of code because the app was pre-split into threads set up in a pipeline. It supported a multi-master, distributed, map/reduce equivalent using worker threads [still within 1000 lines].

Consider the second loop parallelization case. It's easy enough for a programmer to see that loop A and loop B are disjoint and put them in separate threads (e.g. A and B). But, if one is aware of this, the splitup can be done even if loop A and B share some data because one can control the synchronization between threads precisely. Extend this to 40-50 threads that have a more complex dependency graph.

Note that latency means that a given thread A will deliver its results to thread B in a finite/precise/predictable/repeatable amount of time. In video processing, each stage must finish processing within a the allotted for a video frame [usually 1/30th of a second]. With extra buffering, that can be relaxed a bit, but the average must be 1/30th and can't vary too widely (e.g. no frame could take [say] 1/2 second).

Thus, the AC, although snide, is partially right. If I were doing an implementation, I believe the result would be better not using openMP. But, I've got 40+ years doing realtime systems. Not everybody does. Most consumers of openMP [and/or MPI] are usually scientists/researchers who are [no doubt] experts in their field, but they're usually not expert level programmers. And, they usually don't have the restrictions imposed by a realtime system. Notable exceptions: programming for MRI/PET/etc machines.

No, the mc68000 always had supervisor/user mode [I was the chief systems programmer for a startup company that designed/manufactured/sold 68000 microprocessor systems and I'm quite familiar with it]. It also had an external MMU chip, which was almost unusable in practical systems [you couldn't use just one--you needed many of them]. Most companies [mine and others (including Sun)] developed their own MMUs from FPGAs.

It had a 16 bit physical data buses, but logically [how a programmer saw it] was 32 bits. It had 8 data registers and 8 address registers. The address registers were 32 bit, but only the lower 24 bits were used [just like the IBM 370].

You might be thinking of a virtual memory capable MMU, which was available as an external chip for the 68020 and integrated on die in the 68030. Note that while the 68010 is listed as having virtual memory support [via restartable instructions], it really couldn't be used easily for virtual memory.

The 68000 was one of the first 32 bit architecture chips, along with the IBM 370 [mainframe] and the VAX. At the time, the 68000 was vastly superior technically/architecturally to the 16 bit Intel 8086. Intel realized this and initiated a marketing blitz that won the day. This is chronicled in Regis McKenna's book "The Regis Touch".

See https://en.wikipedia.org/wiki/... and https://en.wikipedia.org/wiki/...

It would require a majority of some sort. Say 60% to start a boycott. And, like whitehouse.gov/change.org [and I forgot moveon.org], one endorses an action that they themselves will take. Others are free to follow or not. And, since a [detailed] explanation for the boycott must be provided [which can be fact checked], this helps limit the "fanboy factor".

Also, if this really took off, people would use their votes [more] responsibly, because it's a double edged sword. You may vote for a boycott of product X [and you may get it]. But, your favorite product Y may become boycotted [possibly without merit]. Once the latter happens, you will learn to use your votes responsibly.

And, I think you missed the point about a limited time boycott. It could be 3 months, 6 months, 1 year, etc. That's enough for the corp to feel some pain but it's not permanent. Also, it doesn't preclude individuals from buying anyway (e.g. Maybe there's a boycott on Mattel, but it's Christmastime and your daughter will be heartbroken if she doesn't get a Barbie doll. Even I wouldn't argue against that one.)

Well, yes and no.

Yes explains why Donald Trump gets any press at all. [Side note/disclaimer: I'm a Democrat and disagreed with most (but not all) of John McCain's political positions, but I've never questioned his patriotism, his valor, or heroism--being tortured for five years in the Hanoi Hilton and living to tell about it]. It disappoints me that Trump seems to be getting any traction for these egregious statements of his. In this instance, the "wisdom of the masses" really is quite dumb.

But, no. Google Play's ratings are usually in the ballpark. I have an Android phone and now I don't download anything with a rating less than 3. That's because I used to and I was uninstalling within 2-3 minutes.

Also, I used to subscribe to the "yes" notion [the masses must be wrong], so in their respective heydays, I skipped over "The Beatles" and "Abba". I decided to revisit along the way. Now, I'm a fan of both.

I think Abe Lincoln said it best: "You can fool all the people some of the time, and some of the people all the time, but you cannot fool all the people all the time."

Microsoft came up with an API to handle buffer overflows that take buffer descriptors [that have base/end/length] instead of mere pointers (e.g. memcpy --> memcpy_safe).

But, trying to retrofit that over a code base of tens of millions of lines of code isn't easy and has it's own set of problems for QA'ing the result. For example, suppose you do a retrofit for certain code sections, do a full QA. You may break every system in the world because your QA suite missed something. With Win10, hopefully, automatic rollback on recent changes will be part of the newer "continuous update" model. With that, the risk of adding some additional checking will be smaller, so MS will be encouraged to do more code review and cleanup.

Further, WinX, by architectural design and needless complexity, has many more avenues of attack than Unix/Linux/*BSD POSIX systems. Buffer overflow is but one, and it's the easiest to spot in a code review.

Case in point: Stuxnet

Before getting to the centrifuge controllers, stuxnet had to penetrate windows. It did so by putting attack code in a printer font. The WinX print spooler [inside the kernel] executed code in user space memory from ring 0. This is bad design for two reasons:
(1) putting a print spooler in the kernel at all [on all other above systems, the spooler is just a utility].
(2) Executing any code from user space memory by the kernel running at ring 0 [This is architecturally impossible by the other OSes]

This is [very old] legacy code from the MS/DOS days when there was no supervisor/user mode distinction [on an 8086]. In other words, they never bothered to change this in 20+ years. Contrast this to the fact that most Unixes back then used mc68000's which came out at the same time and did have supervisor/user modes baked into the hardware. None of the POSIX based systems have any way at all for the kernel to do what WinX was doing [the calldown to user space].

More than adorable, sometimes they actually do. Petitions for cell phone unlocking and net neutrality were acted upon. I know, because I signed both petitions and eventually got response emails saying that action would be taken, based upon the petition. For some other petitions, the response is [politely] either "bad idea", "good idea but not something we can do within current law", etc.

But, I think you locked onto one small part of my post [using whitehouse.gov as an example of a petition system] and missed the rest of it. I also cited change.org and there have been cases where companies have reversed policy based on change.org petitions.

If you're looking for enforcement, try rereading the last paragraph of my original post.

Formalizing the meritocracy a bit: How about a "consumers' union" [no relation to the org/mag] website that works like a central clearing house:

- Any member can post a boycott request, with an explanation as to why: bad product, invasive advertising (popups, etc.)
- Members upvote the request by signing on to the boycott
- No downvotes to prevent astroturfing by the advertisers
- With enough votes, all members agree to boycott the product/advertiser for the given period (say 1-5 years)

This is how change.org or whitehouse.gov/petitions work. More loosely, this is how Google Play works [e.g. rate program as 1]

There are many sites that have forums where people review/complain about products, but they are scattered.

The site could even link boycotts to product barcodes, so with a smart phone app, you scan the barcode of a product you want to buy, and it tells you if it's been blacklisted. Even if you signed on, you're still free to "cheat" and buy the product if you so wish [As Julia Child used to say: "When you're in the kitchen, who's to know"].

The mere threat of a product getting on the list, or a 10% drop in sales if actually on it, would be enough to get manufacturers to change.

Thanks for the link.

I had looked at PPAPI when it first came out. At the time, pepper flash was broken, even in Chrome, so I pointed Chrome at the NPAPI version Firefox was using [there was still a Chrome config option to do so].

After I posted, I started looking around to see what the current state of the art was and felt there would be a plugin/extension of some sort that would allow PPAPI.

Google wasn't trying [that hard] to help either. They could have done the Firefox port [they have more resources] and then publish a patch file. In that case, Mozilla refusing a done deal patch would have been more condemning. Remember, at the time, NPAPI was the standard [deliberately ignoring Windows Explorer :-)]

Linus [Torvalds] did this with Gnome/GTK. He complained about a number of things with Gnome (3?) and produced a patch. The Gnome folks wouldn't even try it.

Google really doesn't like Firefox. Those pesky AdBlock and video download plugins that block ads and download videos from youtube.

And, as far as Adobe goes, they seem to hate Linux for some reason. Flash aside, they've frozen the release they'll offer for Acrobat Reader [*]. There's little technical justification for this as the amount of incremental work for the port from rev-to-rev is even lower than Flash.

[*] IIRC, they had to offer a reader port as a condition of the federal gov't standardizing on the PDF format for documents--tax forms in particular. The quid-pro-quo: If we accept PDF, you [Adobe] have to port the reader to all [reasonable] platforms: WinX, Mac, Linux, BSD, etc.

Of course I thought the dark suits showed up. I said as much here: http://yro.slashdot.org/commen...

That was the correct thing to do. Now, "leaking" could get the developer(s) in much more [legal] trouble [they probably had to sign something prohibiting disclosure in any form]. More likely, and better now, would be for a developer not connected with the original group to recreate the design from scratch (ala Brian Benchoff)

If it were operating on a ham band, the user would need a ham license with the right classification (e.g. the higher the classification [the more difficult the test], the more frequencies you're allowed to use). Ham radio operators would object to their relatively small bands being encroached on.

More likely, the frequency was some "open" frequency, not assigned to anything or specified as needing no license [like WiFi or baby monitors, wireless [non-cell] phones, etc.]. [Overly] large swatches of radio spectrum are designated for military purposes.

It can't be encryption alone. Since WiFi hookups use encryption (e.g. ssh/ssl/tls), that isn't the likely objection. Perhaps, this was a knee jerk reaction at some gov't org (e.g. maybe James Comey made the phone call personally :-) that threatened dire consequences that have no [ultimate] legal basis. However, a protracted legal battle would be in the offing. Not something a mere mortal might be willing to opt for.

As a former ham: RTTY used to be [5 bit] Baudot. Using ASCII was considered encryption [and illegal]. Eventually, things changed and ASCII was allowed.

But, Adobe did not update the Linux Firefox NPAPI version. It's still 11.2.202.481, which was listed as vulnerable.

The NPAPI version is an "extended support" release because Google came up with a new "universal" interface for all OSes, and, decidedly refused to map it on top of NPAPI [in order to kill Firefox in favor of Chrome]. Adobe adopted this and stopped active development on the NPAPI version. And, Firefox refused to support the new interface, saying that NPAPI was just fine.

Meanwhile, I'm still waiting ...

The TFA page cited in the post has an embedded video. It is the "SoundCloud" video player, which my Ghostery plugin blocked.

Or, try "Donovan's Brain" https://en.wikipedia.org/wiki/...