As a long time Mozilla user (since before T-Bird and FF split from the Mozilla suite), I'm glad to see them putting some effort into this project again but it's hard to trust these crack heads!
Well, if they really mess up Thunderbird, I can always switch back to Seamonkey.
It would it harder to send a phishing email if you can't use a href tag to hide the real URL, and the user was forced to copy the url and open it in another browser tab.
If someone could effectively solve the spam issue without censoring...
I've always thought that client side filtering was sufficient to handle spam. That is, the reader decides what articles to filter out rather than relying on a central authority.
It seems this car (the software that is) perhaps was doing the human equivalent of "overdriving its headlights"
In this case, the headlamps are aimed too low. Had they been aimed properly, the pedestrian would have come into view 5 seconds before a possible collision, not 1.5 seconds before.
It shows here suddenly coming into the headlights lit region
It also shows that the headlamps are aimed way too low. Properly aimed headlamps should light up an area about 285 feet in front of the vehicle. At 38 mph, the pedestrian would have come into view 5 seconds before a collision instead of the 1.5 seconds shown in the video.
No human driver could have seen that woman in time to stop
Had the headlamps been aimed properly, they could have. In the video, when the car is traveling at 38 mph (56 feet/second), it takes about 1.5 seconds between the time the pedestrian came into view and when the collision occurred. That means that the headlamps are only lighting up an area 84 feet in front of the vehicle. If the vehicle's headlamps are about 2 feet off the ground, then when they're properly aiimed, they should be lighting up an area about 285 feet in front of the car (VOL headlamps where the left half of the horizontal beam cutoff is 2.1 inches below headlamp height at a distance of 25 feet from the front of the vehicle).
If the pedestrian was visible at 285 feet, it would have taken 5 seconds from the time the pedestrian came into view till when a collision could occur. That would have given the driver a second to react and 4 more seconds to slow down and/or change direction to avoid a collision.
Getting stuck with slack has been tolerable with the XMPP gateway.
I found that using the XMPP gateway would effectively lock up my client for minutes at a time whenever it reconnected. But it worked fine after it finally managed to connect. I ended up switching to the IRC gateway to avoid the connection issues.
Mailing lists aren't as free speech friendly as netnews (particularly when one considers newsgroups carried by many netnews servers such as Usenet) but unmoderated mailing lists are typically more free speech friendly than web forums.
Usenet also had moderated groups. For a discussion list, moderation may be necessary if there's too much spam or spew directed at the group. But if they were to set up an NNTP server instead and limited who they peer with to limit the spam, then they probably could get away without having to moderate the group at all.
Forums have the advantage of being easier to search for those just observing the conversation.
How does that differ from using NNTP to access mailing list archives through a service like gmane? My local email and news client has no problems searching through past messages and is faster than an online forum is.
Having a known viewing platform also has it's advantages - when using email one has to assume text only.
Usually forums have a subset of markup that's available and it seems to differ from platform to platform (i.e., how do I use bold, italic, or underlined text). For a text based mailing list or newsgroup, the standard was *bold*,/italic/, and _underline_. Some clients would even support that type of informal markup when rendering plain text.
The switch to a forum is a good idea so long as email alerts / updates to new content are provided.
It would be nice if they could set up a NNTP server with an email to NNTP gateway for those who want to continue using email and allow for participants to register for accounts to post to the group. It could peer with gmane for archival purposes.
Passwords are bad, but are a lot less annoying than passwords plus 2FA.
If websites would support the client side TLS certificate for authentication, then you could get 2FA by combining that with a username and password. Browsers have natively supported it for decades.
When you register to vote, you go through the process of generating a client certificate that's used as your registration. The client certificate need not carry any information that identifies you other than the fact that you're a registered voter. When you vote online, you use that client certificate to connect to the server and vote.
Each vote is counted and associated with a certificate. You can look up your record by providing your certificate to check how your votes were counted.
I was referring to 386sx. Didn't realise there was a 486sx...I di remember a dx4 though..lots of MHz..80 or 120?
IIRC, the 486 sx processors were clocked at either 25 MHz or 33 MHz (the wikipedia page mentions 16 MHz and 20 MHz versions, but I never had either of those). The math co-processors that you could add on came in either a DX2 or DX4 variety. The DX2 doubled the clock speed (50 MHz or 66 MHz) and the DX4 tripled the clock speed (75 MHz or 100 MHz).
IIRC, it's actually called a Royal burger without reference to the weight in countries that use SI units.
If you want to think in metric, start with integer metric measures and don't worry about conversion.
With regards to soft drinks, they've done this for quite a long time (2 L size). Interestingly enough, convenience stores used to sell 20 fl oz size soft drinks, but a couple of years ago, they changed it to 500 mL (20 fl oz is about 591 mL). But they print 16.9 oz on the package rather than 500 mL for some odd reason.
The Nokia N9 was a staggeringly good phone. I still wonder what would have happened if Nokia had thrown its weight behind it rather than behind the (at the time) pretty poor Windows Phone.
From what I've read, there appeared to be a lot of political issues between the Maemo/Meego and Symbian parts of Nokia which lead to the decision to go with Windows Phone. Like you, I wish that Nokia had gone with Meego and ported existing Symbian applications to the new platform.
PS: My last four phones were a Nokia E71 like you (which I still keep around as my Garmin),
I have a Nokia N95, N97, N8, N9, and a 808. Other than the N95, I used to be able to get free map updates roughly every 6 months for the Nokia/Here maps application. But since Nokia sold its maps division, there doesn't appear to be a way to update the maps on any of those phones. Are you keeping the maps on your E71 up to date? If so, then how?
And as somebody that uses certificate-based logins (ssh) regularly, I wonder what problem they are trying to solve....
A better problem to solve would be to have a more intuitive UI for managing client side TLS certificates. It would be nice if I could just use a client side TLS certificate to authenticate myself on Slashdot instead of (or in addition to) a username and password.
It may not be a private key in a public/private key pair. But it's a secret (key) that is known only to you (private).
That's not correct. It's transmitted over the network and is also known by the server on the receiving end so that they can validate whether or not it's correct. A private key, on the other hand, is never known on the receiving server since it's never transmitted over the network, unlike a password.
When you set up your account, you generate your certificate signing requests for each device you plan to use and send them to service which will verify your identity and sign your certificates. Then you configure your browser to use the certificate when you connect to the website. That will be how you authenticate.
It would be nice if credit card companies implemented something like OAuth based transactions. That is, when you initiate a payment, instead of sending your credit card information to the merchant, the merchant website redirects you to the credit card company's website where you log in and authorize the merchant to charge X amount once to your credit card. That way, you never have to transmit your card details directly to the merchant.
Apply for a signed certificate from the government or business like one would get a signed certificate from a CA for their website. If you lose your private key, then you have to repeat the process (and the government or business revokes your old certificate). Make it time consuming such that people aren't willing to go through the process that often, and they won't be so careless with their private keys.
What would be nice is if more websites supported authentication via client certificates. Then we wouldn't have deal with passwords, two factor auth, or "security theater" questions when authenticating.
You should also make sure you create a nzb file so you have a record of the article message-ids that correspond to your backup. You should also create some par2 files for redundancy so that you can recover your backup in case some articles cannot be found.
As for retention, some commercial usenet providers offer up to 9 years at this point.
Rather than laying down fiber, why not offer satellite based internet service. Right now, there are only two existing providers which offer up to 25 Mbps down, 3 Mbps up. If Google wanted to invest in it, they could start their own service with higher transmission speeds and higher data caps compared to the two existing providers.
I'm not sure how much the investment would cost compared to laying down fiber though.
Slashdot Mirror
As a long time Mozilla user (since before T-Bird and FF split from the Mozilla suite), I'm glad to see them putting some effort into this project again but it's hard to trust these crack heads!
Well, if they really mess up Thunderbird, I can always switch back to Seamonkey.
It would it harder to send a phishing email if you can't use a href tag to hide the real URL, and the user was forced to copy the url and open it in another browser tab.
If someone could effectively solve the spam issue without censoring...
I've always thought that client side filtering was sufficient to handle spam. That is, the reader decides what articles to filter out rather than relying on a central authority.
It seems this car (the software that is) perhaps was doing the human equivalent of "overdriving its headlights"
In this case, the headlamps are aimed too low. Had they been aimed properly, the pedestrian would have come into view 5 seconds before a possible collision, not 1.5 seconds before.
It shows here suddenly coming into the headlights lit region
It also shows that the headlamps are aimed way too low. Properly aimed headlamps should light up an area about 285 feet in front of the vehicle. At 38 mph, the pedestrian would have come into view 5 seconds before a collision instead of the 1.5 seconds shown in the video.
No human driver could have seen that woman in time to stop
Had the headlamps been aimed properly, they could have. In the video, when the car is traveling at 38 mph (56 feet/second), it takes about 1.5 seconds between the time the pedestrian came into view and when the collision occurred. That means that the headlamps are only lighting up an area 84 feet in front of the vehicle. If the vehicle's headlamps are about 2 feet off the ground, then when they're properly aiimed, they should be lighting up an area about 285 feet in front of the car (VOL headlamps where the left half of the horizontal beam cutoff is 2.1 inches below headlamp height at a distance of 25 feet from the front of the vehicle).
If the pedestrian was visible at 285 feet, it would have taken 5 seconds from the time the pedestrian came into view till when a collision could occur. That would have given the driver a second to react and 4 more seconds to slow down and/or change direction to avoid a collision.
Getting stuck with slack has been tolerable with the XMPP gateway.
I found that using the XMPP gateway would effectively lock up my client for minutes at a time whenever it reconnected. But it worked fine after it finally managed to connect. I ended up switching to the IRC gateway to avoid the connection issues.
I've been pushing for a return to mailing lists (listserv-type applications like Mailman, etc.)
An internally hosted NNTP server would work better than a mailing list.
Mailing lists aren't as free speech friendly as netnews (particularly when one considers newsgroups carried by many netnews servers such as Usenet) but unmoderated mailing lists are typically more free speech friendly than web forums.
Usenet also had moderated groups. For a discussion list, moderation may be necessary if there's too much spam or spew directed at the group. But if they were to set up an NNTP server instead and limited who they peer with to limit the spam, then they probably could get away without having to moderate the group at all.
Forums have the advantage of being easier to search for those just observing the conversation.
How does that differ from using NNTP to access mailing list archives through a service like gmane? My local email and news client has no problems searching through past messages and is faster than an online forum is.
Having a known viewing platform also has it's advantages - when using email one has to assume text only.
Usually forums have a subset of markup that's available and it seems to differ from platform to platform (i.e., how do I use bold, italic, or underlined text). For a text based mailing list or newsgroup, the standard was *bold*, /italic/, and _underline_. Some clients would even support that type of informal markup when rendering plain text.
The switch to a forum is a good idea so long as email alerts / updates to new content are provided.
It would be nice if they could set up a NNTP server with an email to NNTP gateway for those who want to continue using email and allow for participants to register for accounts to post to the group. It could peer with gmane for archival purposes.
At least we have gmane for that.
Passwords are bad, but are a lot less annoying than passwords plus 2FA.
If websites would support the client side TLS certificate for authentication, then you could get 2FA by combining that with a username and password. Browsers have natively supported it for decades.
When you register to vote, you go through the process of generating a client certificate that's used as your registration. The client certificate need not carry any information that identifies you other than the fact that you're a registered voter. When you vote online, you use that client certificate to connect to the server and vote.
Each vote is counted and associated with a certificate. You can look up your record by providing your certificate to check how your votes were counted.
I was referring to 386sx. Didn't realise there was a 486sx...I di remember a dx4 though..lots of MHz..80 or 120?
IIRC, the 486 sx processors were clocked at either 25 MHz or 33 MHz (the wikipedia page mentions 16 MHz and 20 MHz versions, but I never had either of those). The math co-processors that you could add on came in either a DX2 or DX4 variety. The DX2 doubled the clock speed (50 MHz or 66 MHz) and the DX4 tripled the clock speed (75 MHz or 100 MHz).
And a Quarter Pounder would be a 100 Grammer.
IIRC, it's actually called a Royal burger without reference to the weight in countries that use SI units.
If you want to think in metric, start with integer metric measures and don't worry about conversion.
With regards to soft drinks, they've done this for quite a long time (2 L size). Interestingly enough, convenience stores used to sell 20 fl oz size soft drinks, but a couple of years ago, they changed it to 500 mL (20 fl oz is about 591 mL). But they print 16.9 oz on the package rather than 500 mL for some odd reason.
The Nokia N9 was a staggeringly good phone. I still wonder what would have happened if Nokia had thrown its weight behind it rather than behind the (at the time) pretty poor Windows Phone.
From what I've read, there appeared to be a lot of political issues between the Maemo/Meego and Symbian parts of Nokia which lead to the decision to go with Windows Phone. Like you, I wish that Nokia had gone with Meego and ported existing Symbian applications to the new platform.
At least I still have and use my N9.
PS: My last four phones were a Nokia E71 like you (which I still keep around as my Garmin),
I have a Nokia N95, N97, N8, N9, and a 808. Other than the N95, I used to be able to get free map updates roughly every 6 months for the Nokia/Here maps application. But since Nokia sold its maps division, there doesn't appear to be a way to update the maps on any of those phones. Are you keeping the maps on your E71 up to date? If so, then how?
And as somebody that uses certificate-based logins (ssh) regularly, I wonder what problem they are trying to solve....
A better problem to solve would be to have a more intuitive UI for managing client side TLS certificates. It would be nice if I could just use a client side TLS certificate to authenticate myself on Slashdot instead of (or in addition to) a username and password.
Every password is a private key.
It may not be a private key in a public/private key pair. But it's a secret (key) that is known only to you (private).
That's not correct. It's transmitted over the network and is also known by the server on the receiving end so that they can validate whether or not it's correct. A private key, on the other hand, is never known on the receiving server since it's never transmitted over the network, unlike a password.
When you set up your account, you generate your certificate signing requests for each device you plan to use and send them to service which will verify your identity and sign your certificates. Then you configure your browser to use the certificate when you connect to the website. That will be how you authenticate.
It would be nice if credit card companies implemented something like OAuth based transactions. That is, when you initiate a payment, instead of sending your credit card information to the merchant, the merchant website redirects you to the credit card company's website where you log in and authorize the merchant to charge X amount once to your credit card. That way, you never have to transmit your card details directly to the merchant.
Apply for a signed certificate from the government or business like one would get a signed certificate from a CA for their website. If you lose your private key, then you have to repeat the process (and the government or business revokes your old certificate). Make it time consuming such that people aren't willing to go through the process that often, and they won't be so careless with their private keys.
What would be nice is if more websites supported authentication via client certificates. Then we wouldn't have deal with passwords, two factor auth, or "security theater" questions when authenticating.
You should also make sure you create a nzb file so you have a record of the article message-ids that correspond to your backup. You should also create some par2 files for redundancy so that you can recover your backup in case some articles cannot be found.
As for retention, some commercial usenet providers offer up to 9 years at this point.
Rather than laying down fiber, why not offer satellite based internet service. Right now, there are only two existing providers which offer up to 25 Mbps down, 3 Mbps up. If Google wanted to invest in it, they could start their own service with higher transmission speeds and higher data caps compared to the two existing providers.
I'm not sure how much the investment would cost compared to laying down fiber though.