To be fair, I can't think of another OS that directly supports the things Mininet wants to do. To make it work on other platforms, they'd first have to implement those from scratch there.
Does FreeBSD nowadays provide some form of network isolation like it is available with Linux network namespaces? Nothing relevant shows up in the likely places, so I don't think it does.
BIOS just runs whatever is in the first 512 byte sector.
Unless it fits in 512 bytes this is not a "kernel" but is just instructions to jump to another address, where there is more small bootstrap code that loads another program, maybe a bootloader that loads another program, maybe a kernel.
Those who multiboot Windows with some other OS that uses disklabels may notice that Windows expects to always be the first OS. Any other bootstrap code put into that first sector will be overwritten by a Windows install.
Does anyone disagree that UEFI has the capability to be an OS itself?
If it is only used as a "BIOS" then is it unreasonably adding the surface area for bugs and attacks? Is it much larger and more complex than legacy BIOS?
Is this trade-off proportional to the benefits it provides: obviating need to for developers to understand backwards compatibility?
The point of UEFI is not to avoid the need for kernel developers to know how to get into 64-bit mode. If you can't manage to get a computer to do that pretty easily, kernel programming is not for you, and this is mostly limited to the bootloader anyways.
As much as people like to rag on it, UEFI provides a lot of benefits:
- UEFI graphics firmware improves compatibility, and makes things like PCI pass through of GPUs to virtual machines much easier/possible.
- UEFI allows for much faster boot times by cutting out a lot of 16-bit mode/32-bit mode transitions that BIOSes generally used.
- Every operating system doesn't need to fight over the master boot record of your drive, with UEFI they can live in relative peace.
- Things that were simply impossible with a lot of BIOS implementations (e.g. Booting off > 2TB hard drives) are now possible.
It's over-engineered, but so is ACPI (IMO To an even greater degree). Does anyone want to return to the old plug-and-play compatibility mess?
> It's over-engineered, but so is ACPI (IMO To an even greater degree). Does anyone want to return to the old plug-and-play compatibility mess?
In my experience, those who like to rag on UEFI, for whatever problem they deem it to suffer from, are rarely interested in providing other options or solutions to the problems UEFI provenly solve.
That's true of any piece of tech. The solution to C++'s problems didn't come from the people who avoided that language entirely, it came from Mozilla, who are up to their eyeballs in C++. People who hate Sexprs still haven't come up with a good replacement.
They've got XML
Many of the people behind that were Lispers. And anyways, I said a GOOD replacement.
But yeah, the solutions to a problem with a system don't come from the people who hate its guts and won't touch it: It comes from people who use it, need its functionality, and need those warts fixed.
Well my initial thought was a PCIe card, but it could likely just as well be an SD or such if set up right. And yeah, you can get an approximation of it using _nix and clever mounts.
But i was thinking about having the initial OS sit on an actual ROM chip with a flash chip next to it on the same board/die.
You should not close apps because you may interfere with tracking your location and other data collection.
Data collection is necessary to enrich your "user experience". When we know what you want we can fulfill your every wish! Just say "OK, Google". It will be great!
The developers behind this crap do not hear from satisfied users. Because the truth is no one really cares about this stuff. They care about things like reception and battery life...
except for some nerds like the ones who comment on HN who can easily point out all the stupidity of these "business" models.
When users are like puppets on a string, helplessly dependent. When there are no alternatives, no competition. Is that a business? And I suppose shooting fish in a barrel is game of skill.
Oddly enough, Googlers read HN comments and frequently defend the company, speaking only for themselves of course. Why should they care that anyone sees Android for what it really is? Whining nerds do not count, right? So why pay attention to what they think?
If developers of Android and iOS had any respect, if they had a conscience, then they would not be usurping people's computing resources for their own ends. Sure, users will be oblivious to what is going on and they will not complain. That does not mean it's OK to do these things.
Well, it was a rant rather than information. And I disagree with it from the beginning:
> You should not close apps because you may interfere with tracking your location and other data collection.
That's bullshit reason - you'd write a background service, not try to stop users from closing the app. For any single application I'm using I'm happy for it to be cached rather than restarting every time. This is just arguing against a cache layer, because <made up reason>.
Going offtopic from the rant to an Android development question, if I may - I thought background services were shut down brutally at random times, and hard to keep running reliably unless some app which uses them is open? I'm a newbie to Android dev, but I have an app which (attempts to) maintain an always-on connection, and I've gone with a foreground service because that doesn't get killed (as often).
> A started service must manage its own lifecycle. That is, the system does not stop or destroy the service unless it must recover system memory and the service continues to run after onStartCommand() returns.
A started service shouldn't be killed randomly - after all, that's how the downloads are handled - you don't see those disappearing without a reason.
Downloads are generally handled via foreground services (one significant difference is that foreground services show up as an icon in your notification area, notice downloads or Play Store updates appear there?). Background services are more like OLE in the sense of they let you set your app up so another app can ask it for stuff.
This is why I didn't get to it until the edit. If I could be sure I wouldn't offend my clients, one of the first questions I'd ask is "are you a nerd?" As it is I have to couch it as "what's your background? are you technical?" and risk getting pinned as a condescending asshole when all I'm asking is "do you want me to tell you what the opcodes are doing to the transistors or do you want to tell me how the machine is 'feeling'?
The real question, I guess, is "do you have the knack"?
Ever tried bitlbee? Not sure how well it's keeping up with the new protocols but years ago it was a way to consolidate at least a few of the older ones into a single application. Also not sure why this idea has not been replicated. Maybe it has.
The idea has been replicated in XMPP as so-called transports, which maps other protocols to XMPP. This arguably works better than bitlbee and other IRC gateways, since XMPP is a superset of many protocols, while IRC is a subset of many protocols.
https://en.wikipedia.org/wiki/XMPP#Connecting_to_other_proto...
I can join chatrooms in my XMPP client by joining a multi-user chat, like maemo%irc.freenode.net@irc.netlab.cz. It may seem useless at first, but I have found out that when on a train and using IRC directly, I timeout much more often than if using XMPP in the same situation.
In the "last generation" of chat apps, there were certainly a lot of multiprotocol messengers. Trillium and Pidgin come to mind, and were way more popular with bitlbee.
is this project linux only?