The Linux Foundation Forms Open Source Effort To Advance IO Services (linuxfoundation.org)
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.
BUGS
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?
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.
Pain is merely failure leaving the body
MS-DOS was more or less a CP/M clone. Unless I misremember, the first version didn't even have folders.
"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.
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 forced to use pselect(), and so we can't simply say that nobody should ever use select().
And there really is no longer an argument for it anymore. There used to be a performance argument, but it's gone now: at FD_SETSIZE's usual value of 1024, a poll() of size 1024 in linux uses only 64KB. A copy of 64KB on modern computers is going to be dwarfed by the overhead of doing a syscall.
http://www.top500.org/statisti...
That's some hobby.
98.8% of the top 500 supercomputers run linux. The other six run unix. Not on the list: Windows.