The Linux Foundation Forms Open Source Effort To Advance IO Services (linuxfoundation.org) 46
The Linux Foundation is announcing FD.io ("Fido"), a Linux Foundation Project. FD.io is an open source project to provide an IO services framework for the next wave of network and storage software. Early support for FD.io comes from founding members 6WIND, Brocade, Cavium, Cisco, Comcast, Ericsson, Huawei, Inocybe Technologies, Intel Corporation, Mesophere, Metaswitch Networks (Project Calico), PLUMgrid and Red Hat.
Architected as a collection of sub-projects, FD.io provides a modular, extensible user space IO services framework that supports rapid development of high-throughput, low-latency and resource-efficient IO services. The design of FD.io is hardware, kernel, and deployment (bare metal, VM, container) agnostic.
Architected as a collection of sub-projects, FD.io provides a modular, extensible user space IO services framework that supports rapid development of high-throughput, low-latency and resource-efficient IO services. The design of FD.io is hardware, kernel, and deployment (bare metal, VM, container) agnostic.
Re:No thanks, I'll stick with Windows (Score:5, Informative)
You don't have any Juniper or Cisco gear at any of your "mission-critical" sites?
If you do, there's plenty of Linux running underneath.
Re: No thanks, I'll stick with Windows (Score:5, Informative)
"Juniper uses FreeBSD & Cisco use their own proprietary operating system called ios (yup, same name as apple's mobile O/S)"
Cisco has a number of "operating systems":
- IOS, used on older router platforms and Catalyst switches (which are now limited mostly to use as access switches)
- IOS-XR which runs on high-end routers (CRS, ASR9K, C12K), which is based on QNX
-IOS-XE which runs on current entry-level to mid-range routers (ASR1K), which is Linux-based
-NX-OS which powers most current Cisco data-centre offerings (Nexus), which is Linux-based
If you have Cisco equipment and no Linux, your equipment is most likely all EOL or very close to it.
Re: (Score:1)
Microsoft has a strong reason to ensure performance and stability in their products: recurring revenue. Otherwise common sense dictates they would have gone out of business a long time ago.
Hobby software like Linux doesn't have that priority so it has no place in my mission-critical installations. But it's certainly fine for browsing, email and playing games.
No shit, Sherlock.
Linux file system corruption questions on Stack Exchange. [google.com]
Re: (Score:2)
Hobby software like Linux doesn't have that priority so it has no place in my mission-critical installations. But it's certainly fine for browsing, email and playing games.
Exactly! That's why the Microsoft's Hotmail servers ran BSD for so long. Because Windows wasn't fine for email.
Re: (Score:2)
Don't forget that DOS started out as a Unix flavor...
Wow. You know, I had completely forgotten that. Please post more of this interesting history.
Re: (Score:3)
MS-DOS was more or less a CP/M clone. Unless I misremember, the first version didn't even have folders.
Re: (Score:2)
Wow, down-voted twice.
Looks like MIcrosoft just got off work...
Re: (Score:3)
http://www.top500.org/statisti... [top500.org]
That's some hobby.
98.8% of the top 500 supercomputers run linux. The other six run unix. Not on the list: Windows.
FIDO Alliance (Score:2)
GREAT... Just great... This will surely not cause the least bit of confusion at all with the existing FIDO Alliance. https://fidoalliance.org/ [fidoalliance.org]
Re: (Score:1)
The link doesn't mention 'Fido' at all, it's only confusingly in the summary. FYI there is also the good old FidoNet [wikipedia.org].
How about Linux fully support POSIX first? (Score:2, Interesting)
BUGS [die.net]
POSIX requires that opening a file with the O_APPEND flag should have no affect on the location at which pwrite() writes data. However, on Linux, if a file is opened with O_APPEND, pwrite() appends data to the end of the file, regardless of the value of offset.
Or is that too high a standard?
Re: (Score:2)
What things would those be? SSDs have logical blocks, which are analogous to, and often larger than, hard disk sectors. If you don't allocate on logical block boundaries you'll wear through the SSD's write endurance far faster. The filesystem itself still needs to manage allocations and free space in some reasonable-sized unit. You're not going to be able to remove the need for "sectoring" from either direction.
Pronunciation (Score:1)
FD.io ("Fido")
That's not how that works, in any language. Just call it FDIO, or go register fi.do [www.nic.do] which is available if someone is willing to pay up.
Fd.io is Fido? Huh? (Score:1)
I just use SystemD for that (Score:1)
... ducks
Aimed at idiots? (Score:1)
Architected as a collection of sub-projects, FD.io provides a modular, extensible user space IO services framework that supports rapid development of high-throughput, low-latency and resource-efficient IO services. The design of FD.io is hardware, kernel, and deployment (bare metal, VM, container) agnostic.
How about learning to do IO without C++ streams to hold your pee-pee? Or anything like that?
Doing high-speed IO is no different than figuring out how to get the best performance from ANY hardware. You can't do it while ignoring the hardware. And abstracting away everything hides that.
It's really simple: you can't run any hardware anywhere near its design limits if you ignore the design.
the Open Group needs to up its game (Score:2)
this is the result of the failure of the Open Group to provide a POSIX standard to do fast file descriptor checking. poll() and select() are absurdly inefficient and just about everyone with a kernel has invented their own faster alternative. your move Open Group!
Re: (Score:3)
POSIX has just fucked this up.
I mean, consider the simpler goal: deprecating select(). select() is completely unusable in nontrivial applications, or in any library that might simply be in a process space that might have more than FD_SETSIZE file descriptors -- with the failure mode being memory corruption in practice, because who bothers checking FD_SETSIZE?
The problem? POSIX hasn't even managed to incorporate ppoll()! So, if you're wanting to portably combine signal handling and FD monitoring, you're forc