csirac2

Hence the fine line of having some pretense of complying with free software license terms but still violating their intent in practice.

Have you ever had to resort to these extreme redistribution terms for any other commercial distro?

"Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to associate it with the Trademarks. Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries."

So now I don't understand why anyone bothers building Ubuntu-derived docker images... perhaps that's the intent?

[1] http://www.ubuntu.com/legal/terms-and-policies/intellectual-...

In any case, many parts of the field simply don't have the software engineering discipline to pull off proper "big data" workflows. Advances in commodity hardware, stronger programming tools for ad-hoc work, and "cloudification" toolchains will probably delay a lot of what used to require proper engineering effort from maturing.

Not to mention there's plenty of fertile ground solving problems which by now can be answered with merely "annoyingly non-small" rather than "big data" techniques.

Back on topic, I guess this is why more exotic secure operating systems (seL4/Genode, etc) are focused mainly on "smaller", non-x86 CPU architectures (ARM/PPC/etc).

It's this lack of legal process which means that the safe harbor agreement did not provide equivalent protections required by the charter, without even considering the spying angle.

And so the safe harbor agreement was found not to provide equivalent protections as required by the charter.

Xen provides very basic (but safe) message/event channels between VMs. Basically this becomes your IPC, and the VMs become user processes.

With a new enough CPU with the correct memory virtualization features, xen can scale to many thousands of domUs. And with each domU only taking up slightly more resources than a typical user process, this is a completely reasonable approach.

Again, your Hypervisor becomes the OS which has to worry about the baremetal, and the VMs replace user processes.

I intend to playing with MirageOS seriously myself next year.

Edit: some dependencies in an example MirageOS app: https://mirage.io/wiki/technical-background#ModularOSLibrari...

But it is a restrictive license. Its "plague"-ness comes from its incompatibility with other licenses. Or at least, in the case of ZoL/CDDL and Linux/GPL, the crippling practical realities of the resulting kernel module binaries that are a derived work trying to impose restrictions on each other. That's why you can find precompiled modules on the ZoL website, but never in a distro.

That's a legitimate criticism, but as you say, also its defining feature.

My take away was that the main point against safe harbor is that EU citizens have no legal standing or other access to recourse against US companies accused of breaches, so it does not provide an equivalent level of protection as the charter is supposed to provide.

The truth is that the GPL is a pretty restrictive license. I don't think it's fair to blame anyone for the fact that it's not compatible with much. That's its defining feature and the main reason people choose it; so if it blocks ZoL, it's working as intended.

Which I consider a great loss. ZFS is fantastic.

I use the BSD 2-clause license on my own stuff, but I can think of situations where I'd rather use GPL.

Ouch. I suppose carb ratios weren't so big back then (admittedly, it wasn't for me either, being diagnosed in the late '90s). But I still measured myself so many times a day that the pharmacist thought I was scamming the PBS for test strips somehow (our subsidized medicines scheme here in .au). As a curious teenager I was able to develop a mental picture of what my BSL did when I ate certain foods after a few months of 10+ measurements per day. So, even if I didn't have an actual carb ratio figured out, I "knew" by trial and error how much insulin different foods needed.

Even so, I've fallen off the wagon a few times. I got so used to having specialists and doctors tell me what a great job I was doing on my own, I had an embarrassingly long period between specialists. To the extent that I stayed on humulin for quite a few years longer than I otherwise would have if I'd seen a specialist (newer insulins are way faster-acting and easier to live with).

This story has certainly prompted me to re-evaluate where I am now; complacency is a silent killer.

BMS in a laptop mostly just has to keep the battery safe and avoid unnecessary charge/discharge cycles. In a more complex system trying to salvage every joule of energy and maximize lifespan of each cell, the fact that batteries are less efficient to charge (or discharge) the closer they are to full (or empty) might be taken into account when deciding which to charge/discharge (for example).

A car might dump sudden regenerative braking power into high-C batteries if the main batteries can't take that charge at a given instant.

Satellites often use exotic batteries able to fully charge and discharge 10 times a day for decades at a time, but these have enormous self-discharge rates measured in days. Every chemistry has a unique set of compromises. There is plenty of room for smarter BMS in consumer systems that manage complex battery storage arrays responding to thermal, aging, cycle count, charge and load pressures more intelligently.

But it's not just anticipating demands by learning past behaviour. There's also the problem in any multi-battery system (which is what they cover), let alone with multiple types, optimizing what should take charge or load at a given time. Most people don't realize that many battery chemistries actually don't have a flat efficiency rating with charge: often, the closer to 100% charged you get, the less efficient (more loss) you have compared to what you'll be able to extract later.

For example, charging from 0 to 100% might be 85% efficient for a given battery type. But charging it from 80% to 100% full might only be 40% efficient.

And this variable efficiency also applies to discharge as well. And the variables all change with what recent battery demands have been, let alone the current loads - but also cell voltages, temperature, age and cycle count.

Even planning to cope with self-discharge over days, weeks or months might benefit from smarter BMS. Some battery management systems even take into consideration thermal management (taking into account the cost of ramping up active cooling or throttling charge rates to keep batteries at a temperature efficient for taking charge).

What I mean is: surely a "software-defined" battery would be some kind of redox/flow battery where you can literally adjust the physical properties of the battery to suit the current SOC and current/anticipated system demands.

Don't get me wrong, we need more work like this, particularly if Tesla powerwall home batteries and the like are going to become a thing that we don't want filling landfills with avoidable charge/discharge cycles.

But wow, SDx. I mean, SDR is obvious; software-defined radios clearly replace fixed hardware with programmable IFs and tonnes of DSP. Similarly, networks can be software-defined if they replace discrete stand-alone equipment with fewer tiers of more capable hardware delineated more by connectivity/performance than function.

When it comes to this paper though, nothing is being replaced. And again, it's useful work, particularly in the context of consumer applications (cf. aerospace which has already had to produce systems that do funky, adaptive, predictive, cooperative load/charge management across multiple battery chemistries).

I don't know what I'm saying. It's an interesting paper, but as someone working on low-power systems and exploring different battery chemistries for different things, the whole SDx angle somehow cheapens it... but perhaps I'm just weird.

http://arstechnica.com/information-technology/2015/09/fcc-op...

Yes, that's a legitimate concern, but there's a small consolation that this is a problem only for existing SoC architectures doing 5GHz. The new regs don't rule out new SoC architectures which would implement the enforced separation in silicon somehow. Although you're still stuck not having access to modular transmitter rules but that was the case already.

> To make sure I understand, this would be an incentive for mobile phone manufacturers (for example) to continue to have separate radio firmware, even if they move to cheaper SoC designs, correct?

Indeed, although I have oversimplified somewhat - some basebands do run on the same CPU as the OS, but something resembling a secure hypervisor (with secured boot, among other things) is used to enforce isolation between the baseband and OS (see OKL4).

We already use firmware blobs on WiFi chips. It's why OpenWRT and friends are locked into old kernel versions for some routers: they don't have the source to the WiFi radio blob and can't recompile or reverse-engineer to make it work on newer kernels with different ABI. It's why we have a /lib/firmware directory for certain drivers in Linux: the device doesn't bother with flash memory, you have to load its firmware onto the device every power cycle into the DSP chip's memory.

So for many devices currently in existence, separate radio firmware is already how things are architected.

Some devices are flashed though, and don't require the host computer to load its own firmware, which is why I discussed a smaller EEPROM that would store signed config locking down the RF parameters and other aspects affecting certification.

Basically separate radio and OS firmware are how mobile phones currently work. That's why you see separate baseband versions from your OS version info in "about this phone": these new rules for SDR devices (separate to U-NII discussion here) will actually require a whole new FCC approval for each radio firmware change.

EDIT: And we haven't properly distinguished FCC approval process differences between modular WiFi transmitters (Eg. miniPCI-e cards) used in laptops and more expensive routers, which can self-contain and solve these issues by themselves without requiring the host device to care about U-NII security measures at all, versus cheaper/integrated products that may be crappy enough to require security measures in the main host device firmware in order to guarantee the radio firmware integrity to the FCC's satisfaction.

Yes. In the actual regs (which nobody seems to read), they suggest a list ("including but not limited to") a number of mechanisms by which manufacturers may choose to control the portion of their radio software that would impact the validity on their RF testing/validation/compliance results. One of them is signed firmware blobs: to me, that's the easiest, cheapest non-invasive method for WiFi module makers that won't create a huge compliance burden on the host device manufacturer. You go from having to load an unsigned firmware blob anyway, to a signed one. Which is a huge step in the right direction for firmware security anyway. As for modules which don't have blobs but do have the means to create non-compliant emissions just through the driver: it doesn't seem like much of a stretch that they could run new region-locked revs of their modules, or at least move those previously adjustable RF parameters/behaviours over to a signed image in a $0.10 SPI EEPROM chip.

All of this isn't just a PITA for users, it's a PITA for the device manufactures as well.

Particularly for laptop manufacturers. They could save $5 locking down the entire laptop, something they've never been able to do even when they try, or they could spend the extra $5 and get the module that's got a stand-alone certification and only requires them to submit a reference to the module's own FCC approval and some demonstration that the gain of the antennas in their product are in-spec.

The article is continuing to imply that the FCC is explicitly banning alt firmware for 5GHz WiFi devices. That is only the case if the module manufacturer fails to come up with any other way of getting their device approved. I don't see anywhere in the regs where banning alt. firmware is a goal of the regs.

Given that this also means a brave new world of region-locked/region-specific 5GHz WiFi devices, and the added compliance burden for integrators ("host device manufacturers") trying to use modular transmitters that rely on host device manufacturer controls to achieve FCC approval, I am hopeful that this will change the way that WiFi manufacturers lock down their radio firmware - and that is exactly what the FCC wants.

The situation where a modular transmitter places additional avoidable test/conformance/approval burden on the host device will also be a PITA for manufacturers, not just end-users.

Check my other comment here https://news.ycombinator.com/item?id=10256905

The new regs themselves do not state this requirement. It lists several possibilities for manufacturers to guarantee conformant emissions from their device, several which will continue to allow 3rd-party OS firmware.

Admittedly, the brave new world looks like region-locked devices and cheaper routers that truly are locked down in the exact ways we don't want, but that is not a hard FCC requirement, just a side-effect of the new regs on APs that have poor separation between OS and radio module.

    There are plenty of uses for radio software that don't involve going outside approved frequencies.

Unlike 2.4GHz ISM, nothing gives you the right to transmit on 5GHz U-NII bands (well, there's a bit that overlaps with secondary amateur spectrum) than otherwise permitted through the same FCC approvals process every device manufacturer must undergo.

That was the case before the new rules. Now the new rules are imposing sucky requirements for U-NII device software security.

However, that's been largely misinterpreted in every discussion I've seen recently.

For some context, check out https://wirednot.wordpress.com/2014/01/07/what-else-is-in-th...

You really don't want U-NII devices configured for Japan to be stomping on licensed spectrum in the US; you also need all that power negotiation, radar/interference avoidance algorithms in your radio so we don't get the same 2.4GHz mess happening in 5GHz.

    Do you have a link for that? I'd like to see it...

    "2. What prevents third parties from loading non US versions of the software/firmware on the device? Describe in detail how the device is protected from "flashing" and the installation of third party firmware such as DD-WRT."

It even says that follow-up questions may be asked. As someone familiar with regulatory compliance processes in another country (.au), just because you answer in the negative does not mean your application will be rejected - your other responses (see the rest of the questions to see how redundant they are) will be taken into consideration.

Even though we have the old joke where our equivalent of the FCC has an unofficial motto, "We're not happy until you're not happy", even bureaucrats have enough imagination to see that scripted questions can't capture every single possible way to meet the underlying requirements for a given regulatory compliance issue.

The questions are centered around identifying how the device is restricted from operating outside of the conditions asserted and tested in the conformance documentation submitted with the FCC registrant's application. That's not an unreasonable expection from a spectrum regulator's POV, but it is terrifying given that this will likely mean region-locked (or region-specific) devices - choosing a country from a drop-down list will become a thing of the past (after all, 5GHz is carved up quite differently in different parts of the world compared to 2.4GHz, where things are already a complete mess).

Whilst you might find that "OMG, these questions seem to assume that the FCC wants only OEM-approved firmwarez", as per the DD-WRT wording this is because the questionnaire has been written from the assumption that these drastic measures are necessary to meet the new regulations. If you read the proposed regs themselves, carefully [2], I don't see anywhere where the "host device" is explicitly required to control OS firmware unless this is the only means that the registrant can meet the U-NII security requirements.

It doesn't help that we have a whole new population of people trying to read and understand these documents (me included). They use the term "software" rather loosely, and you have to have some background understanding of how the existing FCC registration/approval/certification process works (difference between an approval for a host device vs module etc).

I even see people mixing up the SDR rules. Technically an SDR product must undergo a completely new FCC approval process with new validation test results/proof of conformance for every firmware update! There's no way WiFi router AP vendors are going to go down that path; this is reserved for things like mobile phone baseband firmware that change infrequently and are profitable enough (check out Qualcomm's profits) to actually afford to be able to do this.

This [2] basically summarizes the intent behind the U-NII security requirements:

    Manufacturers must implement security features in any digitally modulated
    devices capable of operating in any of the U-NII bands, so that third parties
    are not able to reprogram the device to operate outside the parameters for which
    the device was certified. The software must prevent the user from operating the
    transmitter with operating frequencies, output power, modulation types or other
    radio frequency parameters outside those that were approved for the device.
    Manufacturers may use means including, but not limited to the use of a private
    network that allows only authenticated users to download software, electronic
    signatures in software or coding in hardware that is decoded by software to
    verify that new software can be legally loaded into a device to meet these
    requirements and must describe the methods in their application for equipment
    authorization.

[2] http://www.ecfr.gov/cgi-bin/retrieveECFR?gp=1&SID=9a15d7771e...

Edit: I guess you meant the Ars article! Here it is:

http://arstechnica.com/information-technology/2015/09/fcc-ac...

    Ars is attempting to schedule an interview with the FCC to explore this issue in
    more depth. So far, the commission has only told us that “versions of this open
    source software can be used as long as they do not add the functionality to
    modify the underlying operating characteristics of the RF [radio frequency]
    parameters. It depends on the manufacturer to provide us the information at the
    time of application on how such controls are implemented. We are looking for
    manufacturers of routers to take more responsibility to ensure that the devices
    cannot be easily modified.”

After all, preventing APs from stomping on licensed spectrum due to wrong country selection seems to be half of what's driving all this anyway.

This only impacts an OEM/importer's ability to gain FCC approval/certification for new devices.

If you're not slapping FCC stickers on things, or are using something that never had an FCC sticker on it in the first place, this doesn't impact such apparatus (you always needed a separate license to operate HackRF & friends).

That's because unlike 2.4GHz, 5GHz has been carved up very differently in different parts of the world (each place has had its own evolution of technology and spectrum pressures).

To such a degree that this isn't even about power and frequency. As an FCC registrant seeking to slap FCC stickers on your new/imported devices, you'll be required to submit proof of conformance documentation which demonstrates you've properly implemented radar avoidance in your frequency hopping/spread spectrum algorithms.

Finally, the FCC has made it obvious that this aimed at the transmitter module, not the overall device. And so, "banning" OpenWRT and other 3rd-party/alt firmwares would only be required if that's the only half-arsed way a manufacturer can hope to comply with the new regs.

In future, I'd hope hardware becoming better isolated from radio components, this ruling (and similar around the world) are essentially mandating region-locked devices, so we might see something similar to what's happening in mobile phones (Eg. baseband radio firmware separately versioned/updated from OS firmware).

    Which, in practice, means any computer/electronic device that has a radio in it.