Until this past school year, we had 20-odd elementary schools running off 4 Mbps / 0.77 Mbps ADSL links.:( Schools with a full lab of 30 computers, a library lab of 6-10 computers, plus at least 1 computer per classroom.
We even had a handful of sites running off 2 Mbps point-to-point wireless. And one site running on an E1/T1 (1.5 Mbps).
And all of them chomping at the bit to get iPads, Chromebooks, and Android tablets into the school.:(
We gave up waiting for the province (who manages school Internet connections) to upgrade their connections (there's about a 3-year wait list). Especially once we learnt their "next generation Internet" recommends E10 (10 Mbps) for an elementary and E100 (100 Mbps) for a secondary school.:(
Many years ago, we were part of a city-wide initiative (that fizzled out after 2 years) to run fibre to all admin sites, secondary schools, and city buildings, so we have gigabit fibre links between our school board office and the in-town secondary schools.
This past year we've been putting up Ubiquiti point-to-point wireless links between elementary schools and secondary schools. This has upgraded their connections to 100 Mbps (with 60 Mbps actual). Still part of the provincial network, and it's freed up a lot of money for us to be able to upgrade the few out-of-town sites and sites without line-of-site to another school.
4 Mbps is not "broadband" by any definition. And 10 Mbps is barely "broadband" for a single-family household. 25 Mbps needs to be the minimum definition for a family dwelling, and 100 Mbps should be the minimum for any kind of school or multi-person building.
It's only expensive because you are doing it wrong.
Instead of having multiple different providers all running their own copper, cable, and fibre into each building, duplicating the work, it really should be handled like a proper utility.
There aren't 6 different power cables running into your dwelling, even if there are multiple power providers in the county/state/country. There's 1 cable that multiple providers use.
There aren't 6 different water lines running into your dwelling, even if there are multiple water providers in the county/state/country. There's 1 set of pipes that multiple providers use.
There aren't 6 different gas lines running into your dwelling, even if there are multiple gas providers in the county/state/country. There's a single gas line that multiple providers use.
Thus, there really shouldn't be multiple copper, cable, and fibre lines into your dwelling. There should be only a single set of fibre that goes into the building that multiple providers can use to send bits to/from your house. Terminate them all in multiple central locations in the city, and let the different Internet, video, TV, phone, whatever-over-IP providers rent space in them to stick their equipment in, and just run patch cables and vlans between them as needed.
It's time to treat IP connectivity as the utility it has become, and to centralise the infrastructure for it. There's no need for each individual ISP/content provider to run their own infrastructure around the country. Stop duplicating the infrastructure. Run fibre once and be done with it.
I'm leery of systems that automatically restart services when they crash, especially if the service just crashes again at startup, and you get into an infinite loop that eventually runs you out of disk space with *.core files.
If you need a system to be up that often, it's much nicer to setup a fail-over system or a cluster, where it doesn't matter if individual daemons or systems are running, so long as there's another to take it's place. Then you have time to investigate why things are failing on one node, and can implement a proper fix.
Auto-restarting crashing daemons is not a feature. It's a band-aid over top of poor system administration.
Is it a hard dependency on logind the daemon? Or a dependency on the logind d-bus interface?
Kwin_wayland has a dependency on the logind d-bus interface, for example. And there's at least one project that implements the logind d-bus interface (don't remember the name of it off-hand). Thus, it's possible to run Kwin_wayland on a Linux distro without systemd installed... and it will use the features of logind... without actually having logind installed.
Boot speed-up is a decent goal, but it should be the last goal, not the first.
My biggest issue with all these parallel boot setups is diagnosing issues at boot time. There's no way to guarantee that two boots will be identical. Boot up and daemon startup are no longer deterministic, and it takes a lot of voodoo hand-waving to diagnose issues with systemd, upstars, and other parallel boot managers.
At least with upstart and Debian's parallel boot setup you could flip a switch to serialise the boot, thus making it deterministic. However, by serialising things, you tend to avoid issues, not solve them.
Not to mention, on most servers and a lot of desktop, the longest part of the boot process is the POST, BIOS, device detection, option ROM loading, and other init stuff that happens *before* the boot loader is run, and long before the init process takes over. Whoop-de-doo, I shaved 10 seconds off the "boot loader, kernel, daemons" process! Never mind that it takes 2 minutes to get to that point.
Windows NT used a STREAMS-based networking stack, culled from some other UNIX (not directly, but using the concepts and frameworks), not a BSD-derived networking stack.
I have no idea how the DOS-based Windows networking stack developed. But it wasn't pulled from any BSD.
A few command-line utilities (ftp.exe is the most common cited one) were pulled from BSD sources, though.
Google searches for "netmap" and "FreeBSD" will give you lots of information on pushing millions of pps through 900 MHz single-core machines. Netmap is also available on Linux. There's even a netmap-enabled version of IPFW that allows you to do packet filtering and routing completely in userspace, again will millions of pps. IPFW is also available on Linux, although I don't know if the netmap-enabled version is.
Google searches for "openconnect" and "FreeBSD" will give you lots of information and blog posts from the Netflix guys about why they picked FreeBSD, and how it all works, including details on the networking.
Google searches for "Adrian Chadd", or "RSS scaling", or similar terms will show you threads and posts on various FreeBSD mailing lists with information detailing a lot of the MSS/RSS work that's going into FreeBSD 11, and several projects that build off that. Those also have links to other information around sockets and similar.
Google searches for "NUMA" and "FreeBSD" will bring up mailing list threads that cover the different projects being undertaken to improve the CPU affinity and thread locality and all that jazz.
Sure, it would be nice if the OP had posted links to the info, but it's not like the information is secret or hard to find.
There are already e-libraries out there that just have computer stations and ebook download terminals. And I believe Apple? was trying to build a couple more.
Not to mention all the time spent waiting for the 17 different CDN services to respond to download content, all the time spent waiting for the 23 different ad networks to respond to download content, all the time spent waiting for the various DNS servers to respond with the correct IPs, etc.
Sure, the actual downloads of the various bits of data is very fast. But that's the shortest/quickest part of loading a web page. And all the other bits and bobs and bottlenecks are the same, regardless of what speed of network connection you have.
They need to stop with the hybrid crap where there are two drivetrains, and the pure-electric crap with horrible range and non-existent charging networks.
The ultimate EV is one with a gas/diesel generator that does nothing but charge the batteries to provide virtually unlimited range using the existing gas station network.
Stick a battery pack that can handle ~150 Km (~100 miles) into the EV. That covers just about everyone's daily city driving.
Then install a small gas or diesel generator into the car. All that generator does is charge the battery. It doesn't power the wheels, it doesn't drive the car, it doesn't to anything except provide electrical power to the car.
That way, you have the means to use the EV for long trips. Need more than ~150 Km range? Fill up the little gas tank and carry on as per normal.
The GM Volt is so close to being the perfect EV. All they have to do is remove the non-electric drivetrain, disengage the gas motor from the wheels, and tune the gas motor to run as a generator, and that's it.
Except that after years of polite "you need to fix this" requests and no follow-up from Kay... what do you consider the appropriate response? This isn't the first time Linus has called him out. But it's the final time; the time that broke the proverbial camel's back.
Kay's been a kernel developer for years, and has clashed with Linux many times in the past, all for the same reasons: Kay patches something, breaks a lot of things, says everyone else has to fix their code to work around the things he broke as it's "not his problem". Linux has finally had enough of that attitude.
Those are all issues with the cable and Lightning protocols, not the actual, physical connector.
The problem with MicroUSB and even full-sized USB is that stupid tongue in the middle of the socket that goes inside the plug on the cable. That tongue can be easily broken by moving the device with the cable plugged in. I've snapped that off a phone and a desktop now. And there's no way to fix it without replacing the entire socket... not easy when it's soldered to the motherboard.
The Lightning socket/plug is going in the right direction. The contacts should be on the outside of the plug on the cable, and along the inside walls of the socket. The plug should be solid (no holes), and the socket should be just a hole (no pins, tongues, or whatnot).
Compare the headphone jack/socket. Connectors around the inner wall of the socket and on the outside of the plug. Plug is solid. Socket is a hole. Impossible to plug it in wrong. Take design cues from that, from the Lightning connector, hell even the old mini Christmast lights got it right.
Pins and tongues inside of sockets that a plug has to go around is just dumb. Didn't we have enough issues with bent pins on VGA/Serial/Parallel/PS2 ports to realise that was the wrong way to do things?
What's funny about that is that we use VNC-tunnelled-over-SSH everyday (remote helpdesk connections to Windows and Linux stations) without issues. Even when the remote desktop has dual-monitors configured, although that can take a bit of horizontal and/or vertical scrolling of the local VNC client window.
Tunnelling over SSH is not slow. Especially if you enable the NONE cipher on boths ends.:) Not recommended if you are going over public Internet links, but can work wonders within an organisation.
Tunnelling X11 over SSH can be slow, but can also be made fast using NX. Downside to that is that it's full-desktop remoting, not per-application remoting. But it works wonders for staff and students to access their Linux accounts at the schools from home (even across ADSL links).
We can even watch 480p youtube videos in Firefox via VNC-over-SSH across ADSL links (it's choppy but watchable). E10 (10 Mbps) sites make it no different than watching locally (with the exception of the complete lack of sound). Using NX makes even the ADSL link enjoyable. And that's all done over SSH (without compression enabled in the SSH client/server).
IOW, tunnelling over SSH is not slow. Whatever app/protocol you are tunnelling will determine the "speed" of the remote app.
Slashdot Mirror
Until this past school year, we had 20-odd elementary schools running off 4 Mbps / 0.77 Mbps ADSL links. :( Schools with a full lab of 30 computers, a library lab of 6-10 computers, plus at least 1 computer per classroom.
We even had a handful of sites running off 2 Mbps point-to-point wireless. And one site running on an E1/T1 (1.5 Mbps).
And all of them chomping at the bit to get iPads, Chromebooks, and Android tablets into the school. :(
We gave up waiting for the province (who manages school Internet connections) to upgrade their connections (there's about a 3-year wait list). Especially once we learnt their "next generation Internet" recommends E10 (10 Mbps) for an elementary and E100 (100 Mbps) for a secondary school. :(
Many years ago, we were part of a city-wide initiative (that fizzled out after 2 years) to run fibre to all admin sites, secondary schools, and city buildings, so we have gigabit fibre links between our school board office and the in-town secondary schools.
This past year we've been putting up Ubiquiti point-to-point wireless links between elementary schools and secondary schools. This has upgraded their connections to 100 Mbps (with 60 Mbps actual). Still part of the provincial network, and it's freed up a lot of money for us to be able to upgrade the few out-of-town sites and sites without line-of-site to another school.
4 Mbps is not "broadband" by any definition. And 10 Mbps is barely "broadband" for a single-family household. 25 Mbps needs to be the minimum definition for a family dwelling, and 100 Mbps should be the minimum for any kind of school or multi-person building.
It's only expensive because you are doing it wrong.
Instead of having multiple different providers all running their own copper, cable, and fibre into each building, duplicating the work, it really should be handled like a proper utility.
There aren't 6 different power cables running into your dwelling, even if there are multiple power providers in the county/state/country. There's 1 cable that multiple providers use.
There aren't 6 different water lines running into your dwelling, even if there are multiple water providers in the county/state/country. There's 1 set of pipes that multiple providers use.
There aren't 6 different gas lines running into your dwelling, even if there are multiple gas providers in the county/state/country. There's a single gas line that multiple providers use.
Thus, there really shouldn't be multiple copper, cable, and fibre lines into your dwelling. There should be only a single set of fibre that goes into the building that multiple providers can use to send bits to/from your house. Terminate them all in multiple central locations in the city, and let the different Internet, video, TV, phone, whatever-over-IP providers rent space in them to stick their equipment in, and just run patch cables and vlans between them as needed.
It's time to treat IP connectivity as the utility it has become, and to centralise the infrastructure for it. There's no need for each individual ISP/content provider to run their own infrastructure around the country. Stop duplicating the infrastructure. Run fibre once and be done with it.
I'm leery of systems that automatically restart services when they crash, especially if the service just crashes again at startup, and you get into an infinite loop that eventually runs you out of disk space with *.core files.
If you need a system to be up that often, it's much nicer to setup a fail-over system or a cluster, where it doesn't matter if individual daemons or systems are running, so long as there's another to take it's place. Then you have time to investigate why things are failing on one node, and can implement a proper fix.
Auto-restarting crashing daemons is not a feature. It's a band-aid over top of poor system administration.
Is it a hard dependency on logind the daemon? Or a dependency on the logind d-bus interface?
Kwin_wayland has a dependency on the logind d-bus interface, for example. And there's at least one project that implements the logind d-bus interface (don't remember the name of it off-hand). Thus, it's possible to run Kwin_wayland on a Linux distro without systemd installed ... and it will use the features of logind ... without actually having logind installed.
Boot speed-up is a decent goal, but it should be the last goal, not the first.
My biggest issue with all these parallel boot setups is diagnosing issues at boot time. There's no way to guarantee that two boots will be identical. Boot up and daemon startup are no longer deterministic, and it takes a lot of voodoo hand-waving to diagnose issues with systemd, upstars, and other parallel boot managers.
At least with upstart and Debian's parallel boot setup you could flip a switch to serialise the boot, thus making it deterministic. However, by serialising things, you tend to avoid issues, not solve them.
Not to mention, on most servers and a lot of desktop, the longest part of the boot process is the POST, BIOS, device detection, option ROM loading, and other init stuff that happens *before* the boot loader is run, and long before the init process takes over. Whoop-de-doo, I shaved 10 seconds off the "boot loader, kernel, daemons" process! Never mind that it takes 2 minutes to get to that point.
The K1 in the SHIELD Tablet uses standard ARM Cortex-A15 cores, not the Denver CPU cores detailed in this story. Very different beasts.
Windows NT used a STREAMS-based networking stack, culled from some other UNIX (not directly, but using the concepts and frameworks), not a BSD-derived networking stack.
I have no idea how the DOS-based Windows networking stack developed. But it wasn't pulled from any BSD.
A few command-line utilities (ftp.exe is the most common cited one) were pulled from BSD sources, though.
Except when you start talking about netmap. :) That's a userspace network stack that can push millions of pps, on sub-GHz systems.
There's even a netmap-enabled version of the IPFW packet filter that runs in userspace, filtering millions of pps on sub-GHz systems.
And there's an applications ecosystem starting to grow around netmap that keeps all network-related packet processing in userspace.
As a twist, netmap and IPFW are also available on Linux, and provide better performance than the in-kernel network stack and iptables. :)
Google searches for "netmap" and "FreeBSD" will give you lots of information on pushing millions of pps through 900 MHz single-core machines. Netmap is also available on Linux. There's even a netmap-enabled version of IPFW that allows you to do packet filtering and routing completely in userspace, again will millions of pps. IPFW is also available on Linux, although I don't know if the netmap-enabled version is.
Google searches for "openconnect" and "FreeBSD" will give you lots of information and blog posts from the Netflix guys about why they picked FreeBSD, and how it all works, including details on the networking.
Google searches for "Adrian Chadd", or "RSS scaling", or similar terms will show you threads and posts on various FreeBSD mailing lists with information detailing a lot of the MSS/RSS work that's going into FreeBSD 11, and several projects that build off that. Those also have links to other information around sockets and similar.
Google searches for "NUMA" and "FreeBSD" will bring up mailing list threads that cover the different projects being undertaken to improve the CPU affinity and thread locality and all that jazz.
Sure, it would be nice if the OP had posted links to the info, but it's not like the information is secret or hard to find.
What makes this thing truly "Raspberry Pi-compatible" is that it uses the same Broadcom SoC. There's nothing Samsung about this thing.
AdBlock+ is available for Chrome as well. Why not use the same product everywhere?
They're talking about the Score, not the compression algorithm. And your link doesn't mention anything about the Score.
Actually, in the context of the headline, it *does* have an apostrophe, just not where they put it: Starbucks'
After all, the wireless charging mats belong to Starbucks.
There are already e-libraries out there that just have computer stations and ebook download terminals. And I believe Apple? was trying to build a couple more.
Not to mention all the time spent waiting for the 17 different CDN services to respond to download content, all the time spent waiting for the 23 different ad networks to respond to download content, all the time spent waiting for the various DNS servers to respond with the correct IPs, etc.
Sure, the actual downloads of the various bits of data is very fast. But that's the shortest/quickest part of loading a web page. And all the other bits and bobs and bottlenecks are the same, regardless of what speed of network connection you have.
Yes, exactly.
They need to stop with the hybrid crap where there are two drivetrains, and the pure-electric crap with horrible range and non-existent charging networks.
The ultimate EV is one with a gas/diesel generator that does nothing but charge the batteries to provide virtually unlimited range using the existing gas station network.
Stick a battery pack that can handle ~150 Km (~100 miles) into the EV. That covers just about everyone's daily city driving.
Then install a small gas or diesel generator into the car. All that generator does is charge the battery. It doesn't power the wheels, it doesn't drive the car, it doesn't to anything except provide electrical power to the car.
That way, you have the means to use the EV for long trips. Need more than ~150 Km range? Fill up the little gas tank and carry on as per normal.
The GM Volt is so close to being the perfect EV. All they have to do is remove the non-electric drivetrain, disengage the gas motor from the wheels, and tune the gas motor to run as a generator, and that's it.
Except that after years of polite "you need to fix this" requests and no follow-up from Kay ... what do you consider the appropriate response? This isn't the first time Linus has called him out. But it's the final time; the time that broke the proverbial camel's back.
Kay's been a kernel developer for years, and has clashed with Linux many times in the past, all for the same reasons: Kay patches something, breaks a lot of things, says everyone else has to fix their code to work around the things he broke as it's "not his problem". Linux has finally had enough of that attitude.
Those are all issues with the cable and Lightning protocols, not the actual, physical connector.
The problem with MicroUSB and even full-sized USB is that stupid tongue in the middle of the socket that goes inside the plug on the cable. That tongue can be easily broken by moving the device with the cable plugged in. I've snapped that off a phone and a desktop now. And there's no way to fix it without replacing the entire socket ... not easy when it's soldered to the motherboard.
The Lightning socket/plug is going in the right direction. The contacts should be on the outside of the plug on the cable, and along the inside walls of the socket. The plug should be solid (no holes), and the socket should be just a hole (no pins, tongues, or whatnot).
Compare the headphone jack/socket. Connectors around the inner wall of the socket and on the outside of the plug. Plug is solid. Socket is a hole. Impossible to plug it in wrong. Take design cues from that, from the Lightning connector, hell even the old mini Christmast lights got it right.
Pins and tongues inside of sockets that a plug has to go around is just dumb. Didn't we have enough issues with bent pins on VGA/Serial/Parallel/PS2 ports to realise that was the wrong way to do things?
Except when the OEM puts the USB slot in upside down. Like the Nexus 7. Or the front USB slots on a lot of desktops.
You were going on about how X11-over-SSH is so slow, and using VNC is so much better/faster as there's no SSH in the way.
I was saying that SSH is not slow, as we use VNC-over-SSH all the time.
And that X11-over-SSH is not slow, as we use the NX Client all the time (which is X11-over-SSH).
X11 by itself can be very slow over the network. But it doesn't have to be (just look at NX as an example).
Thus, doing things in a similar way to X11 doesn't mean it will be inherently slow.
What's funny about that is that we use VNC-tunnelled-over-SSH everyday (remote helpdesk connections to Windows and Linux stations) without issues. Even when the remote desktop has dual-monitors configured, although that can take a bit of horizontal and/or vertical scrolling of the local VNC client window.
Tunnelling over SSH is not slow. Especially if you enable the NONE cipher on boths ends. :) Not recommended if you are going over public Internet links, but can work wonders within an organisation.
Tunnelling X11 over SSH can be slow, but can also be made fast using NX. Downside to that is that it's full-desktop remoting, not per-application remoting. But it works wonders for staff and students to access their Linux accounts at the schools from home (even across ADSL links).
We can even watch 480p youtube videos in Firefox via VNC-over-SSH across ADSL links (it's choppy but watchable). E10 (10 Mbps) sites make it no different than watching locally (with the exception of the complete lack of sound). Using NX makes even the ADSL link enjoyable. And that's all done over SSH (without compression enabled in the SSH client/server).
IOW, tunnelling over SSH is not slow. Whatever app/protocol you are tunnelling will determine the "speed" of the remote app.
Since when does Netflix have their own datacentres? Everything Netflix does is hosted in the Amazon cloud.
Isn't Quartz based on Display PDF, though?