They seem complementary: There are technical and functional checks you can do to avoid misuse or abuse. And then there is reputation to check if you have previously conducted in a bad manner. All good predictors of things you don't want.
I only read 3000 cycles and a possible 300 mile radius which translates into 900.000 miles total lifetime. If that is only 22% true then it would be fine.
Why do you give status updates? What does it tell them? Nothing. That is why they are so bored.
What they really need to be able to do is 'manage'. Giving them status updates (about service levels) are not the information they are looking for. Managing is about achieving a goal having certain risks and costs. Your goal is having happy customers about the service you provide. Even though that is formalized through SLAs, that will never be why a customer stays or goes.
The reason that it is difficult to tell anything about the 'process' 'providing service' is because it is a very undefined business process requiring skills on all sorts of areas. I prefer to say something about the aspects of the process. These may include e.g.: security management, incident management, hardware management, external supplier management, hr management, personnel knowledge management, building management, computer system management, release management,... You notice that I put the word management behind every aspect. That is because all these aspects require activity on your part (and choices are to be made). Choose your aspects in a practical manner (lets say between 20 and 30 items).
The next thing is that you identify the following for every aspect: You describe shortly the current situation (e.g. operating system mgmt: We are running Debian Wheezy with automatic updates on wednesday because that is our service maintenance window. Sometimes packages are necessary from upstream). You describe the 'ideal situation' (e.g. for personnel knowledge mgmt: We would like all tasks to be able to be completed by two persons because people have holidays or may be sick. We have weekly knowledge sessions). You describe already known issues that need to be fixed. And lastly you give a grade: 1-5 if this aspect is a risk getting you goal achieved and 6-10 if you are (firmly) in control of the aspect. Remember: A 10 is probably a waste of money and other resources.
If you covered your area well, described all relevant aspects, you will then get something new: You are able to identify the largest risks (even if they did not go wrong) and unique selling points. In 9 out of 10 cases you will realize you are far from done with your work. In the 10th case you realize you can do your job with fewer people. When you have identified your aspects you should (partly) report on that.
Btw A great marketeer once held this speech. Since you are presenting something you should know a little about marketing (which is about making people enthousiastic).
In the email world there are 'reputation' providers that will give an IP address a score (e.g. from 0 to 100). On many domains if your 'reputation' is too low, the email bounces. However we are heading towards an IPv6 world where ip-reputation is too hard (too many addresses). So you need another way to base your reputation on (e.g. your domain name or email address).
Who is providing the content and are they trusted (you better prove you are trustworthy). Just another option.
Spamfilters are not written in RFCs. Spam is a authentication/authorization security issue that needs to be solved and not a single RFC stepped in to solve that. So it was solved otherwise.
The next big item is email-over-IPv6. Rules are not yet set but one thing is clear: You cannot effectively block on ip address. An alternate method has to be used. My guess is that it will be SPF and/or DMARC. The big inbox-providers (Hotmail/Gmail/Yahoo/Aol) have something to protect (their business model) so they MUST have an effective anti-spam method. They might start to require DMARC or SPF before they accept email (so they can validate the domain with a personal whitelist or reputation-system). It might actually drive IPv6 acceptance.
That is your opinion. And you can do what you want with your mailing list server.
And any domain owner can configure DMARC if (s)he wants to. Which leaves the recipient mailserver operator free to NOT accept the message from your mailinglist server. Your opinion is not internet-law (even if it is written in RFC).
Please inform yourself better. Even DMARC-haters agree on the fact that mailinglist-software can be changed so that DMARC-enforcing domains are not put in the From or Reply-To field.
Just counter that with: "Well, employers are just like other people. And I happened to to be employed by a bad example who tried to f*** me over. I presume you are more reliable?"
Not at all. We probably have the best roads in the world. Silky smooth, hardly makes noise, very well maintained. I drove through Europe a while ago from the Netherlands to Italy and the NL was the quietest. We invest a lot in infrastructure and roads are part of that. The onlly thing that is not nice is the speedbumps.
I was in North Caroline a while ago and it reminded me of a bad stretch of Polish road. Canada is ok, given its two seasons (winter and road repair season?).
True, most of it. They are actually cutting down on public lighting after peak hours due to energy savings. They still light crossings but reduce it on lengthy parts where not much happens. Most inner cities, which are compact to US standards, remain lighted.
Some have overseen the fact that a heartbeat in one layer isn't always enough. The OS tcp/ip heartbeat might have different timeout than preferrable for TLS and you may not have the option to change the one from the OS for different reasons. The second issue is that you want to have the proper exception handling (to correct the issue you had with the bad connection). Just getting a new connection may not cut it.
I had the issue recently when a redundant system had a failover due to maintenance. The firewall of the second system, which took control of the IP address, just ignored the packets (TCP session failover was of no use here) and the messaging system thought that the message was sent (tcp was not complaining for a while). I fixed this by letting the messaging system send an ACK after every message and activating the heartbeat of the messaging system. Any failover is now detected quickly and resolves in making a new connection (and when this happens while sending a message: retry). The original situation always wasted a dozen messages and then corrected by making a new connection.
People in the US do not care for another. They are polite but do not care, not really. It shows when people are at their most vulnerable: No job, in prison, poor, health issues.
Slashdot Mirror
Did I open a can of worms here?
-2 seconds, jeesh that is fast (it must be very heavy to warp time like that, f-ing wormhole).
They seem complementary: There are technical and functional checks you can do to avoid misuse or abuse. And then there is reputation to check if you have previously conducted in a bad manner. All good predictors of things you don't want.
What eight years?
I only read 3000 cycles and a possible 300 mile radius which translates into 900.000 miles total lifetime. If that is only 22% true then it would be fine.
It is not like they have issues hauling things into space (https://en.wikipedia.org/wiki/Ariane_%28rocket_family%29). Or am I missing something?
we were innocent and naive. Now you can only trust open source.
Sorry to reply to myself, but I particularly like this post. It did not go into aspects very well but I liked the attention for other numbers.
Why do you give status updates? What does it tell them? Nothing. That is why they are so bored.
... You notice that I put the word management behind every aspect. That is because all these aspects require activity on your part (and choices are to be made). Choose your aspects in a practical manner (lets say between 20 and 30 items).
What they really need to be able to do is 'manage'. Giving them status updates (about service levels) are not the information they are looking for. Managing is about achieving a goal having certain risks and costs. Your goal is having happy customers about the service you provide. Even though that is formalized through SLAs, that will never be why a customer stays or goes.
The reason that it is difficult to tell anything about the 'process' 'providing service' is because it is a very undefined business process requiring skills on all sorts of areas. I prefer to say something about the aspects of the process. These may include e.g.: security management, incident management, hardware management, external supplier management, hr management, personnel knowledge management, building management, computer system management, release management,
The next thing is that you identify the following for every aspect: You describe shortly the current situation (e.g. operating system mgmt: We are running Debian Wheezy with automatic updates on wednesday because that is our service maintenance window. Sometimes packages are necessary from upstream). You describe the 'ideal situation' (e.g. for personnel knowledge mgmt: We would like all tasks to be able to be completed by two persons because people have holidays or may be sick. We have weekly knowledge sessions). You describe already known issues that need to be fixed. And lastly you give a grade: 1-5 if this aspect is a risk getting you goal achieved and 6-10 if you are (firmly) in control of the aspect. Remember: A 10 is probably a waste of money and other resources.
If you covered your area well, described all relevant aspects, you will then get something new: You are able to identify the largest risks (even if they did not go wrong) and unique selling points. In 9 out of 10 cases you will realize you are far from done with your work. In the 10th case you realize you can do your job with fewer people. When you have identified your aspects you should (partly) report on that.
Btw A great marketeer once held this speech. Since you are presenting something you should know a little about marketing (which is about making people enthousiastic).
I am aware of technical possibilities. I still think it is an option to _not_ use IPs and it may be a valid choice.
In the email world there are 'reputation' providers that will give an IP address a score (e.g. from 0 to 100). On many domains if your 'reputation' is too low, the email bounces. However we are heading towards an IPv6 world where ip-reputation is too hard (too many addresses). So you need another way to base your reputation on (e.g. your domain name or email address).
Who is providing the content and are they trusted (you better prove you are trustworthy). Just another option.
Spamfilters are not written in RFCs. Spam is a authentication/authorization security issue that needs to be solved and not a single RFC stepped in to solve that. So it was solved otherwise.
The next big item is email-over-IPv6. Rules are not yet set but one thing is clear: You cannot effectively block on ip address. An alternate method has to be used. My guess is that it will be SPF and/or DMARC. The big inbox-providers (Hotmail/Gmail/Yahoo/Aol) have something to protect (their business model) so they MUST have an effective anti-spam method. They might start to require DMARC or SPF before they accept email (so they can validate the domain with a personal whitelist or reputation-system). It might actually drive IPv6 acceptance.
That is your opinion. And you can do what you want with your mailing list server.
And any domain owner can configure DMARC if (s)he wants to. Which leaves the recipient mailserver operator free to NOT accept the message from your mailinglist server. Your opinion is not internet-law (even if it is written in RFC).
Please inform yourself better. Even DMARC-haters agree on the fact that mailinglist-software can be changed so that DMARC-enforcing domains are not put in the From or Reply-To field.
Does it mail DMARC-compliant? Mailinglist operators were complaining like the world fell down a few weeks ago.
Are they calling actors cockroaches? Or were they watching politics on 3d?
Just counter that with: "Well, employers are just like other people. And I happened to to be employed by a bad example who tried to f*** me over. I presume you are more reliable?"
And the result is: One person goes to jail and everyone is vulnerable. It seems like a bad trade-off.
or libraries of congress, or liters
Not at all. We probably have the best roads in the world. Silky smooth, hardly makes noise, very well maintained. I drove through Europe a while ago from the Netherlands to Italy and the NL was the quietest. We invest a lot in infrastructure and roads are part of that. The onlly thing that is not nice is the speedbumps.
I was in North Caroline a while ago and it reminded me of a bad stretch of Polish road. Canada is ok, given its two seasons (winter and road repair season?).
True, most of it. They are actually cutting down on public lighting after peak hours due to energy savings. They still light crossings but reduce it on lengthy parts where not much happens. Most inner cities, which are compact to US standards, remain lighted.
Some have overseen the fact that a heartbeat in one layer isn't always enough. The OS tcp/ip heartbeat might have different timeout than preferrable for TLS and you may not have the option to change the one from the OS for different reasons. The second issue is that you want to have the proper exception handling (to correct the issue you had with the bad connection). Just getting a new connection may not cut it.
I had the issue recently when a redundant system had a failover due to maintenance. The firewall of the second system, which took control of the IP address, just ignored the packets (TCP session failover was of no use here) and the messaging system thought that the message was sent (tcp was not complaining for a while). I fixed this by letting the messaging system send an ACK after every message and activating the heartbeat of the messaging system. Any failover is now detected quickly and resolves in making a new connection (and when this happens while sending a message: retry). The original situation always wasted a dozen messages and then corrected by making a new connection.
People in the US do not care for another. They are polite but do not care, not really. It shows when people are at their most vulnerable: No job, in prison, poor, health issues.
@home: Ubuntu, @work: Ubuntu with Virtualbox running windows for email, @work.server: Debian
No dual boot anywhere
This... I don't think about checkout-time any more.
No no ... employer-socialism (it hits a nerve)...