Honestly, who still cares about what Consumer Reports has to say? They are certainly still entertaining, but their reviews have been so flawed for at least the last ten years as to be entirely worthless.
I don't know anything about the Tesla. So, it's conceivable that by sheer luck CR hit on some useful bits of data. But in most likelihood, it's just like all their other publications. Any time I read one of their tests for a product that I'm familiar with, they test some obscure and irrelevant detail and base their entire test on this result. Not surprisingly, good and innovative products tend to fail, and mediocre mass market products get all the praise.
I know that you are joking. But an often overlooked aspect of the international system (aka metric), is the relationship between different units. It's not just the ability to easily scale a single unit up and down by adding a common prefix such as milli or mega.
For instance, 1g of water is exactly 1ml. And even complicated units like N (Newton, a measure of force) can be constructed from basic units. In this case, that would be kg*m/s^2. Note that there is no correction factor needed. You simply multiply the units. That makes physics and engineering a lot easier and less error prone.
Yes, you need to own at least one domain. But you can then use sub domains for everything else. Any cheap domain will do. But yes, it'll cost you on the order of $10/year for all your computation needs
You don't need a separate domain for internal services. Use your external domain and create sub domains. All your internal machines could be on dhcp.public.com and all your containers on vm.public.com. Neither one needs to use publicly routable IP addresses, and in fact you can continue using dnsmasq (or an exquisitely DHCP server) to manage this part of your internal network.
You then operate the Let's Encrypt ACME client in DNS mode to get globally trusted SSL certificates. But nobody other than your internal machines will ever get to interact with those certificates.
There are several other clients apart from CertBot. Take a look. They are all linked from the letsencrypt.org website. You might find something that is a better fit for you.
I think, there are a couple of ACME clients that also act as HTTPS reverse proxies. That could be a really easy option to solve your problem
With Let's Encrypt, it is pretty easy to automate all of the necessary steps. When they launched about a year ago, there were a couple of device manufacturers that wanted to know how to integrate Let's Encrypt into their wireless access points.
Each owner of an access point would automatically be assigned a (sub)domain administered by the device manufacturer. I haven't seen any devices for sale that do this yet, but as SSL becomes more prevalent I'd expect routers to create hostnames such as windos123.wifi567.netgear-secure.com, and to automatically make a certificate available.
You'll need to own at least one domain name (e.g. "example.com"). But it is OK if your internal service is hosted on a sub domain (e.g. "videos.example.com"). So you only need to pay for a single domain name.
The internal host name does not need to be accessible from the internet, just from your LAN. But you need to be able to control DNS for your entire domain. You can then use DNS validation to prove to Let's Encrypt that you control all of "example.com", and they'll issue you a certificate for "videos.example.com", which you can then copy (e.g. with "scp") onto your NAS.
If you don't already have an"always-on" computer, this is well within reach of a cheap raspberry pi
DNS validation is awesome. I have a couple of embedded devices (e.g. a remote KVM switch) that have minimal support for SSL certificates. I was never able to figure out how to use them with traditional CAs. But ACME over DNS was super easy to set up for these devices
If you have hundred domains, you should look at using either a hosting service or a content delivery network. Thanks to Let's Encrypt, almost all of the big players allow you to turn on HTTPS support with a single check box. You do that once and you're all set.
As a nice she effect, your site will get much faster, as it can now use HTTP/2, which has huge performance improvements.
And Google's index will rank you higher.
Also, future browser versions won't show warning messages when they access your site (that hasn't rolled out yet, but all the major browser vendors are working on it).
Finally, you get to use new HTML5 features. A lot of the newer features are only available to encrypted sites
If anything, ACME is a vast improvement over what we had before.
You might not mind 1) obtaining a new client certificate, 2) installing it in the browser, 3) generating and uploading a CSR, 4) proving that you have control over the domain, 5) downloading the new certificate, 6) installing it the server, 7) restarting the server with minimal downtime.
It used to take about 30min of work once a year for each of my domains. It also was a little tedious to schedule, as StartCom only gave a relatively small time window to do so. I think it was only about two weeks or so. But everything considered, for a private site with only one or two domains, it just about bearable.
With Let's Encrypt, things are a lot easier. You set things up once, and certificates will continue renewing automatically in perpetuity. Very little if any maintenance is required, and you can do it on your own schedule. Also, Let's Encrypt is much saner with regards to "subject alternate names". That solves a lot of problems that I used to have with StartCom.
Finally, there is a plethora of different ACME clients to chose from with lots of different feature sets and designs. I don't have first-hand experience with how things look on Mac or Windows, but on most traditional UNIX systems (including Linux), there really is no excuse for not setting up ACME. Also, most of the clients support both HTTP and DNS as way to verify control of the domain. That's huge! It solve a lot of the problems of dealing with complicated firewalls and legacy server software.
The easiest way to switch a legacy service to HTTPS is to install an NGINX reverse proxy in front of it.
As for the certificate, get a free certificate from Let's Encrypt. There are are plenty of options to automate and integrate Let's Encrypt with existing services (e.g. the aforementioned NGINX).
And yes, Let's Encrypt has probably done more for the universal adoption of HTTPS than any other effort -- including everything that Google has done.
If you like Let's Encrypt, please consider donating. They are currently running a fund raising effort: https://www.generosity.com/com...
I mostly agree with Apple moving towards modern standards and eliminating older connectors. So, I generally think it is the right move to switch everything to just USB-C connectors. It might be painful for the transition phase, but as the rest of the industry had already started moving towards USB-C, it only makes sense for Apple to follow suit.
But you do point out a very important use case that simply isn't addressed by USB-C. There frequently is a need to have small devices that can permanently stay attached without any risk of damage. USB-A wasn't originally designed with this use case in mind, but it effectively gained this ability over time. There are SD card readers that fit fully inside of a USB-A socket, there are FIDO-U2F security tokens that do the same, and there are several low-profile USB-A dongles for wireless keyboard/mouse, for WiFi, for Bluetooth, and probably for a couple of other special purposes.
All of these are very legitimate applications, and Apple currently doesn't have a good answer for any of those. I don't really see this need going away anytime soon, either. So, while USB-C is otherwise superior in almost every way, I wish laptops would continue having two or three legacy USB-A ports for "odd" devices. Now as for desktops, they don't really have the same problem with needing low-profile devices. For all I care, they could switch to USB-C only.
I never listen to the radio, but our last Audi rental car would always turn the radio on when the car was started. The only way to disable this "feature" was to completely disable the entire system including the GPS.
Guess what never got used during the entire three week trip?
My Honda Odyssey was showing me in the middle of a building driving diagonally through the block, while my phone showed the accurate position. Both properly tracked the vehicle accelerating and slowing down
O'Reillys books are universally really high quality. Back in the 1990s and 2000s, I'd buy their books pretty much sight unseen. They were never cheap, but they were definitely worth every penny.
These days, there are so many amazing online resources, it is rare that I would get use from a printed book. I am a little sad and nostalgic, but I honestly don't see their business model lasting all that much longer. Even if all of their books were readily and cheaply available online, I probably still wouldn't read them. It's simply the wrong way to present the type of information that I need.
Oh, you want a REPL. Why didn't you say that earlier.
Press SHIFT-CTRL-J and it is right at your fingertips.
Then type:
console.log("Hello world")
and if you want to go fancy, replace that with
alert("Hello world")
There are plenty of great ways for anybody to get started programming. And one the options is in fact right there inside your browser. Javascript traditionally has a bad reputation. But it has matured a lot over time. It is very readily accessible. There is instant gratification without having to write a lot of boilerplate code. And skills learned here can then be transferred to Node.js for writing larger applications.
I would vote you up if I could. There are in fact real technical problems with showing life content in HTML5 videos. And while there are a couple of proposals on how to address this issue, there is so far no consensus among browser makers. I expect things to get better quickly, as all major browsers are rapidly moving away from Flash. But for a small numbers of specific use cases, HTML5 does not quite have an adequate answer.
The bad news is that this will be painful for the smallish number of affected web developers. The good news is that most of the problem cases have been identified and are actively being worked on
I have tried that many times. And it even almost works. But in the long run, there always are problems. Connections stop letting data go through. Clients fail to roam when they should. Bandwidth drops inexplicably.
It's just not a mode that is well supported by most consumer-level hardware. You are much better off buying hardware that was designed as an access point rather than a router.
Yes, this is exactly how WiFi was designed to work. In big cities, the noise floor is so high that frequently, you need one access point per room or two. So, the ability for a client to roam seamlessly is pretty important.
And generally things worked fine that way, back in the day when you could buy WiFi "access points" instead of WiFi "routers". These days, the router function usually gets into the way, though. For many consumer models, you are supposed to be able to selectively disable routing; but in my experience this never works properly. It might seem to work for a day, but then all of a sudden connections keep dropping and become unresponsive. It's just a mode that isn't tested much. And consumer WiFi devices tend to be poorly tested to begin with. Manufacturers care more about rolling out the next cool thing, rather than debugging and fine-tuning existing hardware.
The solution, of course, is to refrain from buying consumer-grade hardware. Instead, you should get semi-professional hardware. I have had amazingly great luck with Ubiquiti's Unifi series of access points. They are not even more expensive than normal consumer-grade hardware. But they simply just work. Put a couple of their access points across the house, and never worry about poor WiFi performance. You can walk all over the house, and you'll never lose connectivity.
The downside is that you'll need a router to plug all these devices into. And ideally, this router should be POE enabled (although, you could use the included POE injectors).
But if you ever wondered how large office buildings make sure their WiFi works correctly, or why some hotels have working WiFi and others never seem to manage; well, now you know. If you spot Unifi access points in the hallways, chances are that WiFi is going to work correctly.
It's probably EGAPS, though. Operating systems haven't been swapping whole processes in a while now. Surely, any OS that can handle gigabytes worth of memory knows how page instead
Honestly, who still cares about what Consumer Reports has to say? They are certainly still entertaining, but their reviews have been so flawed for at least the last ten years as to be entirely worthless.
I don't know anything about the Tesla. So, it's conceivable that by sheer luck CR hit on some useful bits of data. But in most likelihood, it's just like all their other publications. Any time I read one of their tests for a product that I'm familiar with, they test some obscure and irrelevant detail and base their entire test on this result. Not surprisingly, good and innovative products tend to fail, and mediocre mass market products get all the praise.
It's been a recurring pattern for way too long
I know that you are joking. But an often overlooked aspect of the international system (aka metric), is the relationship between different units. It's not just the ability to easily scale a single unit up and down by adding a common prefix such as milli or mega.
For instance, 1g of water is exactly 1ml. And even complicated units like N (Newton, a measure of force) can be constructed from basic units. In this case, that would be kg*m/s^2. Note that there is no correction factor needed. You simply multiply the units. That makes physics and engineering a lot easier and less error prone.
The hostname isn't encrypted, when issuing HTTP over SSL. So any network between you and the internet (I.e. your ISP) has this information.
I think HTTP/2 is a little better in this regard, but it is not yet very widely deployed.
Yes, you need to own at least one domain. But you can then use sub domains for everything else. Any cheap domain will do. But yes, it'll cost you on the order of $10/year for all your computation needs
You don't need a separate domain for internal services. Use your external domain and create sub domains. All your internal machines could be on dhcp.public.com and all your containers on vm.public.com. Neither one needs to use publicly routable IP addresses, and in fact you can continue using dnsmasq (or an exquisitely DHCP server) to manage this part of your internal network.
You then operate the Let's Encrypt ACME client in DNS mode to get globally trusted SSL certificates. But nobody other than your internal machines will ever get to interact with those certificates.
There are several other clients apart from CertBot. Take a look. They are all linked from the letsencrypt.org website. You might find something that is a better fit for you.
I think, there are a couple of ACME clients that also act as HTTPS reverse proxies. That could be a really easy option to solve your problem
With Let's Encrypt, it is pretty easy to automate all of the necessary steps. When they launched about a year ago, there were a couple of device manufacturers that wanted to know how to integrate Let's Encrypt into their wireless access points.
Each owner of an access point would automatically be assigned a (sub)domain administered by the device manufacturer. I haven't seen any devices for sale that do this yet, but as SSL becomes more prevalent I'd expect routers to create hostnames such as windos123.wifi567.netgear-secure.com, and to automatically make a certificate available.
You'll need to own at least one domain name (e.g. "example.com"). But it is OK if your internal service is hosted on a sub domain (e.g. "videos.example.com"). So you only need to pay for a single domain name.
The internal host name does not need to be accessible from the internet, just from your LAN. But you need to be able to control DNS for your entire domain. You can then use DNS validation to prove to Let's Encrypt that you control all of "example.com", and they'll issue you a certificate for "videos.example.com", which you can then copy (e.g. with "scp") onto your NAS.
If you don't already have an"always-on" computer, this is well within reach of a cheap raspberry pi
HTTP/2 requires encryption and gives much better performance than plain old HTTP.
If you want a fast and efficient site, there is no way around getting a valid certificate.
The same is true if you want to use any of the more modern HTML5 features. They're disabled for legacy sites
That's what "certificate transparency" is for. And it's quickly becoming a mandatory feature.
Also, "certificate pinning" can help. But there are pros and cons to it. It's not appropriate for every site.
DNS validation is awesome. I have a couple of embedded devices (e.g. a remote KVM switch) that have minimal support for SSL certificates. I was never able to figure out how to use them with traditional CAs. But ACME over DNS was super easy to set up for these devices
If you have hundred domains, you should look at using either a hosting service or a content delivery network. Thanks to Let's Encrypt, almost all of the big players allow you to turn on HTTPS support with a single check box. You do that once and you're all set.
As a nice she effect, your site will get much faster, as it can now use HTTP/2, which has huge performance improvements.
And Google's index will rank you higher.
Also, future browser versions won't show warning messages when they access your site (that hasn't rolled out yet, but all the major browser vendors are working on it).
Finally, you get to use new HTML5 features. A lot of the newer features are only available to encrypted sites
If anything, ACME is a vast improvement over what we had before.
You might not mind 1) obtaining a new client certificate, 2) installing it in the browser, 3) generating and uploading a CSR, 4) proving that you have control over the domain, 5) downloading the new certificate, 6) installing it the server, 7) restarting the server with minimal downtime.
It used to take about 30min of work once a year for each of my domains. It also was a little tedious to schedule, as StartCom only gave a relatively small time window to do so. I think it was only about two weeks or so. But everything considered, for a private site with only one or two domains, it just about bearable.
With Let's Encrypt, things are a lot easier. You set things up once, and certificates will continue renewing automatically in perpetuity. Very little if any maintenance is required, and you can do it on your own schedule. Also, Let's Encrypt is much saner with regards to "subject alternate names". That solves a lot of problems that I used to have with StartCom.
Finally, there is a plethora of different ACME clients to chose from with lots of different feature sets and designs. I don't have first-hand experience with how things look on Mac or Windows, but on most traditional UNIX systems (including Linux), there really is no excuse for not setting up ACME. Also, most of the clients support both HTTP and DNS as way to verify control of the domain. That's huge! It solve a lot of the problems of dealing with complicated firewalls and legacy server software.
The easiest way to switch a legacy service to HTTPS is to install an NGINX reverse proxy in front of it.
As for the certificate, get a free certificate from Let's Encrypt. There are are plenty of options to automate and integrate Let's Encrypt with existing services (e.g. the aforementioned NGINX).
And yes, Let's Encrypt has probably done more for the universal adoption of HTTPS than any other effort -- including everything that Google has done.
If you like Let's Encrypt, please consider donating. They are currently running a fund raising effort: https://www.generosity.com/com...
I mostly agree with Apple moving towards modern standards and eliminating older connectors. So, I generally think it is the right move to switch everything to just USB-C connectors. It might be painful for the transition phase, but as the rest of the industry had already started moving towards USB-C, it only makes sense for Apple to follow suit.
But you do point out a very important use case that simply isn't addressed by USB-C. There frequently is a need to have small devices that can permanently stay attached without any risk of damage. USB-A wasn't originally designed with this use case in mind, but it effectively gained this ability over time. There are SD card readers that fit fully inside of a USB-A socket, there are FIDO-U2F security tokens that do the same, and there are several low-profile USB-A dongles for wireless keyboard/mouse, for WiFi, for Bluetooth, and probably for a couple of other special purposes.
All of these are very legitimate applications, and Apple currently doesn't have a good answer for any of those. I don't really see this need going away anytime soon, either. So, while USB-C is otherwise superior in almost every way, I wish laptops would continue having two or three legacy USB-A ports for "odd" devices. Now as for desktops, they don't really have the same problem with needing low-profile devices. For all I care, they could switch to USB-C only.
I never listen to the radio, but our last Audi rental car would always turn the radio on when the car was started. The only way to disable this "feature" was to completely disable the entire system including the GPS.
Guess what never got used during the entire three week trip?
My Honda Odyssey was showing me in the middle of a building driving diagonally through the block, while my phone showed the accurate position. Both properly tracked the vehicle accelerating and slowing down
O'Reillys books are universally really high quality. Back in the 1990s and 2000s, I'd buy their books pretty much sight unseen. They were never cheap, but they were definitely worth every penny.
These days, there are so many amazing online resources, it is rare that I would get use from a printed book. I am a little sad and nostalgic, but I honestly don't see their business model lasting all that much longer. Even if all of their books were readily and cheaply available online, I probably still wouldn't read them. It's simply the wrong way to present the type of information that I need.
Oh, you want a REPL. Why didn't you say that earlier.
Press SHIFT-CTRL-J and it is right at your fingertips.
Then type:
console.log("Hello world")
and if you want to go fancy, replace that with
alert("Hello world")
There are plenty of great ways for anybody to get started programming. And one the options is in fact right there inside your browser. Javascript traditionally has a bad reputation. But it has matured a lot over time. It is very readily accessible. There is instant gratification without having to write a lot of boilerplate code. And skills learned here can then be transferred to Node.js for writing larger applications.
I would vote you up if I could. There are in fact real technical problems with showing life content in HTML5 videos. And while there are a couple of proposals on how to address this issue, there is so far no consensus among browser makers. I expect things to get better quickly, as all major browsers are rapidly moving away from Flash. But for a small numbers of specific use cases, HTML5 does not quite have an adequate answer.
The bad news is that this will be painful for the smallish number of affected web developers. The good news is that most of the problem cases have been identified and are actively being worked on
I have tried that many times. And it even almost works. But in the long run, there always are problems. Connections stop letting data go through. Clients fail to roam when they should. Bandwidth drops inexplicably.
It's just not a mode that is well supported by most consumer-level hardware. You are much better off buying hardware that was designed as an access point rather than a router.
Yes, this is exactly how WiFi was designed to work. In big cities, the noise floor is so high that frequently, you need one access point per room or two. So, the ability for a client to roam seamlessly is pretty important.
And generally things worked fine that way, back in the day when you could buy WiFi "access points" instead of WiFi "routers". These days, the router function usually gets into the way, though. For many consumer models, you are supposed to be able to selectively disable routing; but in my experience this never works properly. It might seem to work for a day, but then all of a sudden connections keep dropping and become unresponsive. It's just a mode that isn't tested much. And consumer WiFi devices tend to be poorly tested to begin with. Manufacturers care more about rolling out the next cool thing, rather than debugging and fine-tuning existing hardware.
The solution, of course, is to refrain from buying consumer-grade hardware. Instead, you should get semi-professional hardware. I have had amazingly great luck with Ubiquiti's Unifi series of access points. They are not even more expensive than normal consumer-grade hardware. But they simply just work. Put a couple of their access points across the house, and never worry about poor WiFi performance. You can walk all over the house, and you'll never lose connectivity.
The downside is that you'll need a router to plug all these devices into. And ideally, this router should be POE enabled (although, you could use the included POE injectors).
But if you ever wondered how large office buildings make sure their WiFi works correctly, or why some hotels have working WiFi and others never seem to manage; well, now you know. If you spot Unifi access points in the hallways, chances are that WiFi is going to work correctly.
In the middle of evil there is vi
Eight gigabytes and paging strenuously
It's probably EGAPS, though. Operating systems haven't been swapping whole processes in a while now. Surely, any OS that can handle gigabytes worth of memory knows how page instead