Perhaps... thus turning a lack of capacity into a profit center for the ISP. They're bad enough at having enough capacity as it is, without giving them a profit incentive to make their connections as bad as possible.
For electricity, water and gas, every bit of it you consume has to be produced somewhere and then shipped to you. This isn't true for bandwidth; bandwidth is produced on a constant basis at every link in the internet and is then thrown away if it's not consumed immediately. As a result, any bandwidth used at off-peak times has zero impact on the production cost, because you're using bandwidth that would've had to be thrown away anyway.
Yeah, it looks like the protocol involves sending a UDP packet to 239.255.255.250 port 1900, and waiting for any devices to send a packet back. The return packets will come from the devices' unicast address rather than the discovery multicast address, so you can't rely on normal state tracking to let the return packets in automatically.
The bugs are a bit convoluted, because there's a lot of them and this code originally landed for Mobile before being ported to desktop. There's Bug 1090535... the actual discovery code lives in SimpleServiceDiscovery.jsm.
Nope. Bug 1054959: it's searching your network for Roku or Chromecast devices so you can fling videos and tabs to them.
Re:Great if optimizing the wrong thing is your thi
on
HTTP/2 Finalized
·
· Score: 3, Interesting
No... maybe. It depends.
Amdahl's law is in full force here. There comes a point where increasing the bandwidth of an internet connection doesn't make pages load faster, because the page load time is dominated by the time spent setting up connections and requests (i.e. the latency). Each TCP connection needs to do a TCP handshake (one round trip), and then each HTTP request adds another round trip. Also, all new connections need to go through TCP window scaling, which means the connection will be slow for a few more round trips. Keep-alive connections help a bit by keeping TCP connections alive, but 74% of HTTP connections only handle a single transaction, so they don't help a great deal.
Oh! by the way, not everybody's connection is like yours, specially over mobile networks.
Mobile networks (and, yes, satellite) tend to have high latency, so round-trips are even more of the problem there. Also... when people shop for internet connections, they tend to concentrate on the megabits, and not give a damn about any other quality metrics. So that's what ISPs tend to concentrate on too. You'll see them announce 5x faster speeds, XYZ megabits!!, yet they don't even monitor latency on their lines. And even if your ISP had 0ms latency, there's still the latency from them to the final server (Amdahl's law rearing its ugly head again).
Given all that, I think I'm justified in saying that the main problem with page loading times isn't the amount of data but the number of round-trips required to fetch it. Reducing the amount of data is less important than reducing the number of, or impact of, the round-trips involved. And that's the main problem that HTTP/2 is trying to address with its fancy binary multiplexing.
(Now, if your connection is a 56k modem with 2ms latency, then feel free to ignore me. HTTP/2 isn't going to help you much.)
Re:Great if optimizing the wrong thing is your thi
on
HTTP/2 Finalized
·
· Score: 4, Informative
The main problem isn't the size of the stuff that gets loaded. What's dozens of kb these days? Even a megabyte takes a tenth of a second to transfer on my connection. The problem is latency: it takes more than 100ms for that megabyte of data to even start flowing, let alone get up to speed. That's what the multiplexing is intended to deal with.
That said, the root cause of all this is the sheer amount of unnecessary stuff on pages these days. Fancy multiplexing or not, no request can finish faster than the one that's never made.
Well, it is, but it does sod all to protect that openness, so BSDed software often ends up less open by the time you actually get a copy of it.
The only stuff the GPL doesn't let you do is remove other people's freedom. That should never be a problem unless you were planning to do that in the first place.
For example, you can't run a Minecraft server on an IPv6 address.
Yes you can! This worked fine the last time I tried it.
What didn't work fine was the client. The client actively disables IPv6 support in Java. The bug report is here if you wouldn't mind adding another useless request for them to fix their shit.
Needing to know the MAC address is just a limitation of the nRF24L01+ chip he was using. Conveniently though, the chip has an undocumented feature (or bug) that lets you trick it into giving the full packet, including the MAC address header. The only brute force scanning he ends up doing is to scan through all the different frequencies.
And the "key" is xored with the plaintext to get the "encrypted" text, and the typed character is in a single byte. So you only actually need a single byte of the MAC address.
And it happens to be the first byte, which for these Microsoft keyboards is always 0xCD. So you don't even need to bother figuring out what the MAC address is.
And if SOCKS isn't enough, you can also do ssh -w 42:42 to link a pair of tun interfaces between the two sides. (Slightly less cool because you have to manually configure networking on both ends for it.)
And then the summary decides to hold compression up as the super amazing feature that nobody has ever heard of...
Because FOSS still doesn't place some arbitrary BS restriction on fixing stuff.
Yes, it's true that a lot of users won't have the knowledge to do it, or won't be competent enough. Heck, even the people who can fix bugs won't have the time to fix every bug they encounter. But at least FOSS doesn't just outright ban you from doing it.
It's not meant for an economy. Bitcoin is intended as a way to move your dollars around, not as a replacement for dollars.
It shouldn't be too surprising that Bitcoin is bad at something it wasn't designed to do, but that's not a good reason to avoid using it for what it was designed to do.
And there's a problem. People are going to end up unable to participate in the market, because you need money to do that, and you get money from doing jobs, and you can't get a job if there aren't any to get.
This is going to be a problem for us at some point, and we're going to need to deal with it. Which, knowing us, will probably happen way too late.
Jobs are created by people coming up with ideas for new businesses based on new products
Jobs are created by people who a) come up with an idea for a new business, and b) need people to do something to make that idea a reality.
If it doesn't need people to do it, then no jobs are created. And the set of things that need people (as opposed to automation/robots/AI) to do them is shrinking pretty darn fast.
It's just odd word choices all around. The headline suggests that this is important because it uses an iPhone as its brains (as if a high-speed M&M sorting machine isn't cool by itself), then the body goes on to says that the sorter's creator's blog uses an iPhone as its brains (wait, I thought it was the sorter itself that did that?), and then it strongly implies that other M&M sorting machines can't detect different colors, which makes one wonder how those machines ever managed to sort any M&Ms. Then it implies that this one can't sort M&Ms either, but only "sort" them.
I suspect what it wanted to say was this:
The anonymous author of www.reviewmylife.co.uk has created a new high-speed M&M sorting machine that uses an iPhone to detect the color of the M&Ms while they're in freefall though the machine.
I find this to be really irritating when sellers on eBay do it... but Amazon actually fix shipping prices for Marketplace. For instance, shipping on books/CDs/DVDs/games is $3.99. (Full list.) For sellers on Amazon Marketplace, a price of 1c means "we would've sold this to you cheaper, but Amazon won't let us."
What they ought to do is to just merge the shipping price in with the product price. Combined shipping would make that impossible (since the price would depend on what other items you have in your basket), but Amazon don't even allow that, so adding a book to your basket is going to increase the total shipping cost by $3.99. It makes no sense as a separate figure.
Like we had the upper hand in shutting Code Red, Blaster and the like down?
Those worms weren't self-intelligent and they weren't even trying to hide. Imagine an AI that signs itself up for the 12 month free AWS trial and spends that time not bringing any attention to itself. You can't pull the plug if you don't know which plug to pull. Maybe you don't even realize that a plug even needs pulling.
Or maybe the AI spends its time trying to spread over the internet as far as it can. I doubt we'd ever pull off a shutdown of the entire internet, let alone a complete purge of all executable data on every computer system on the planet, which is roughly what we'd need to do to make sure we got rid of it. I don't think you can rely on "we had a kill switch".
In RHEL 7 and downstreams, you can choose between LVM2, standard partitioning, or btrfs as ways to carve up your disks. It would be nice to have systemd as an option
From what I've heard of systemd, I'm honestly not quite sure whether this was -- as I initially thought -- badly phrased, or if they are in fact planning to roll partitioning into systemd along with everything else.
Slashdot Mirror
Perhaps... thus turning a lack of capacity into a profit center for the ISP. They're bad enough at having enough capacity as it is, without giving them a profit incentive to make their connections as bad as possible.
Because bandwidth works differently to those.
For electricity, water and gas, every bit of it you consume has to be produced somewhere and then shipped to you. This isn't true for bandwidth; bandwidth is produced on a constant basis at every link in the internet and is then thrown away if it's not consumed immediately. As a result, any bandwidth used at off-peak times has zero impact on the production cost, because you're using bandwidth that would've had to be thrown away anyway.
Yeah, it looks like the protocol involves sending a UDP packet to 239.255.255.250 port 1900, and waiting for any devices to send a packet back. The return packets will come from the devices' unicast address rather than the discovery multicast address, so you can't rely on normal state tracking to let the return packets in automatically.
The bugs are a bit convoluted, because there's a lot of them and this code originally landed for Mobile before being ported to desktop. There's Bug 1090535... the actual discovery code lives in SimpleServiceDiscovery.jsm.
Nope. Bug 1054959: it's searching your network for Roku or Chromecast devices so you can fling videos and tabs to them.
No... maybe. It depends.
Amdahl's law is in full force here. There comes a point where increasing the bandwidth of an internet connection doesn't make pages load faster, because the page load time is dominated by the time spent setting up connections and requests (i.e. the latency). Each TCP connection needs to do a TCP handshake (one round trip), and then each HTTP request adds another round trip. Also, all new connections need to go through TCP window scaling, which means the connection will be slow for a few more round trips. Keep-alive connections help a bit by keeping TCP connections alive, but 74% of HTTP connections only handle a single transaction, so they don't help a great deal.
Oh! by the way, not everybody's connection is like yours, specially over mobile networks.
Mobile networks (and, yes, satellite) tend to have high latency, so round-trips are even more of the problem there. Also... when people shop for internet connections, they tend to concentrate on the megabits, and not give a damn about any other quality metrics. So that's what ISPs tend to concentrate on too. You'll see them announce 5x faster speeds, XYZ megabits!!, yet they don't even monitor latency on their lines. And even if your ISP had 0ms latency, there's still the latency from them to the final server (Amdahl's law rearing its ugly head again).
Given all that, I think I'm justified in saying that the main problem with page loading times isn't the amount of data but the number of round-trips required to fetch it. Reducing the amount of data is less important than reducing the number of, or impact of, the round-trips involved. And that's the main problem that HTTP/2 is trying to address with its fancy binary multiplexing.
(Now, if your connection is a 56k modem with 2ms latency, then feel free to ignore me. HTTP/2 isn't going to help you much.)
The main problem isn't the size of the stuff that gets loaded. What's dozens of kb these days? Even a megabyte takes a tenth of a second to transfer on my connection. The problem is latency: it takes more than 100ms for that megabyte of data to even start flowing, let alone get up to speed. That's what the multiplexing is intended to deal with.
That said, the root cause of all this is the sheer amount of unnecessary stuff on pages these days. Fancy multiplexing or not, no request can finish faster than the one that's never made.
Yet. Yet.
There's nothing that says an AI can't do creative jobs. "Our current AIs can't do them" doesn't say anything about our future AIs.
Sure: the GPL strictly states that nobody is allowed to put handcuffs on you. BSD is more along the lines of "anybody can stick handcuffs on you".
If you don't want handcuffs on you, you want the former, not the latter.
Well, it is, but it does sod all to protect that openness, so BSDed software often ends up less open by the time you actually get a copy of it.
The only stuff the GPL doesn't let you do is remove other people's freedom. That should never be a problem unless you were planning to do that in the first place.
For example, you can't run a Minecraft server on an IPv6 address.
Yes you can! This worked fine the last time I tried it.
What didn't work fine was the client. The client actively disables IPv6 support in Java. The bug report is here if you wouldn't mind adding another useless request for them to fix their shit.
Needing to know the MAC address is just a limitation of the nRF24L01+ chip he was using. Conveniently though, the chip has an undocumented feature (or bug) that lets you trick it into giving the full packet, including the MAC address header. The only brute force scanning he ends up doing is to scan through all the different frequencies.
And the "key" is xored with the plaintext to get the "encrypted" text, and the typed character is in a single byte. So you only actually need a single byte of the MAC address.
And it happens to be the first byte, which for these Microsoft keyboards is always 0xCD. So you don't even need to bother figuring out what the MAC address is.
And if SOCKS isn't enough, you can also do ssh -w 42:42 to link a pair of tun interfaces between the two sides. (Slightly less cool because you have to manually configure networking on both ends for it.)
And then the summary decides to hold compression up as the super amazing feature that nobody has ever heard of...
Because FOSS still doesn't place some arbitrary BS restriction on fixing stuff.
Yes, it's true that a lot of users won't have the knowledge to do it, or won't be competent enough. Heck, even the people who can fix bugs won't have the time to fix every bug they encounter. But at least FOSS doesn't just outright ban you from doing it.
It's not meant for an economy. Bitcoin is intended as a way to move your dollars around, not as a replacement for dollars.
It shouldn't be too surprising that Bitcoin is bad at something it wasn't designed to do, but that's not a good reason to avoid using it for what it was designed to do.
there are always jobs where it is cheaper/easier to hire somebody
There have always been. Don't make the assumption that this'll always be true.
And there's a problem. People are going to end up unable to participate in the market, because you need money to do that, and you get money from doing jobs, and you can't get a job if there aren't any to get.
This is going to be a problem for us at some point, and we're going to need to deal with it. Which, knowing us, will probably happen way too late.
Jobs are created by people coming up with ideas for new businesses based on new products
Jobs are created by people who a) come up with an idea for a new business, and b) need people to do something to make that idea a reality.
If it doesn't need people to do it, then no jobs are created. And the set of things that need people (as opposed to automation/robots/AI) to do them is shrinking pretty darn fast.
So?
The GP's point is still entirely valid.
It's just odd word choices all around. The headline suggests that this is important because it uses an iPhone as its brains (as if a high-speed M&M sorting machine isn't cool by itself), then the body goes on to says that the sorter's creator's blog uses an iPhone as its brains (wait, I thought it was the sorter itself that did that?), and then it strongly implies that other M&M sorting machines can't detect different colors, which makes one wonder how those machines ever managed to sort any M&Ms. Then it implies that this one can't sort M&Ms either, but only "sort" them.
I suspect what it wanted to say was this:
The anonymous author of www.reviewmylife.co.uk has created a new high-speed M&M sorting machine that uses an iPhone to detect the color of the M&Ms while they're in freefall though the machine.
but I guess that would've made things too clear.
I find this to be really irritating when sellers on eBay do it... but Amazon actually fix shipping prices for Marketplace. For instance, shipping on books/CDs/DVDs/games is $3.99. (Full list.) For sellers on Amazon Marketplace, a price of 1c means "we would've sold this to you cheaper, but Amazon won't let us."
What they ought to do is to just merge the shipping price in with the product price. Combined shipping would make that impossible (since the price would depend on what other items you have in your basket), but Amazon don't even allow that, so adding a book to your basket is going to increase the total shipping cost by $3.99. It makes no sense as a separate figure.
Like we had the upper hand in shutting Code Red, Blaster and the like down?
Those worms weren't self-intelligent and they weren't even trying to hide. Imagine an AI that signs itself up for the 12 month free AWS trial and spends that time not bringing any attention to itself. You can't pull the plug if you don't know which plug to pull. Maybe you don't even realize that a plug even needs pulling.
Or maybe the AI spends its time trying to spread over the internet as far as it can. I doubt we'd ever pull off a shutdown of the entire internet, let alone a complete purge of all executable data on every computer system on the planet, which is roughly what we'd need to do to make sure we got rid of it. I don't think you can rely on "we had a kill switch".
Maybe if they'd actually take our suggestions or our code. But no.
Makes it kind of hard to contribute anything back to them.
Or perhaps most of their bug searching is done by subcontractors, so it's not technically the NSA finding any of them.
In RHEL 7 and downstreams, you can choose between LVM2, standard partitioning, or btrfs as ways to carve up your disks. It would be nice to have systemd as an option
From what I've heard of systemd, I'm honestly not quite sure whether this was -- as I initially thought -- badly phrased, or if they are in fact planning to roll partitioning into systemd along with everything else.