I doubt that an passive alien race would bother to leave their own gravity well. Hell I doubt a passive species will ever become intelligent int he first place. That said there is little reason for an alien race to care about us, nothing is very useful or unique at the bottom of a gravity well the size of a planet.
It's an issue of population density that is rather curable once we spread out. It's fairly reasonable that they spreading out will keep the aggression in check for a very long time.
You can prove that it effects everybody equally??? That this is no antidote for a select few? You can not ever make that happen. How do you counteract it when an aggressive alien race shows up? Native species becomes dangerous?
Humans need 2 things to thrive, near limitless power and space. Aggression will help us get there, it drives us to risk and to reach.
Look at NASA 60 years ago they strapped a chair to a rocket with less cpu umph that an arduino and made it to the moon. Now they are so worried about any possible failure that it takes them decades to do anything. That is the different between one guy in charge with a mission vs committees upon committees.
Thats just comcast sucking like usual. My optimum linked devices log into comcast routers (transmitting the optimum SSID next to their own) automatically via the sharing agreement they have.
Every comcast, optimum, and others routers are putting out a pile of SSID's and will authenticate via mac address alone. The vast majority of home and small business users end up using whatever the provider gives them.
If they just got our of school, will be working with nobody with more experience than them, and it's a startup with no existing systems, systemd is a great choice for that sort of sysadmins perspective.
Otherwise it fails to give anything compelling useful that could not be done before. It takes a reasonable amount of effort to move to using it with no gain.
They want you to install an app. Yet pretty much a picture of the barcode is all that is needed. Considering the poor state of security on phones the rights are far to course grained. The app needs to connect to the DMV for authentication means it has access to data at all times. You quickly have a heavily encrypted app that can can expand it's scope of permissions with clueless users.
They will I assume want you to hand your phone to the cop unlocked. Maybe your smart and setup a secondary login with only the licence and insurances apps more probably you handed a cop access to your entire digital life. Is that enough protection to secure the phone from state overreach?
Expand it out will bouncers be able to validate the licence? In effect that means the state knows when you went to what club.
Will potential employers be able to use it? Now the state knows every place you ever applied for a job.
Will stores be able to use it to cash a check (I know how many people will use this that still use checks)
Are fake ID's really a problem primarily it's for buying booze and we along with a handful of other first world nations has the highest legal drinking age in the first world.
What does the phone app add over the existing ability for police to pull up a photo id via the barcode or just name and address on the in cruiser laptops.
How portable will this be one state must accept another's ID. Will they build in the same protections? If so how will they be required to do so and held accountable for failing to do so?
At this point a simple name and address should be all that is needed to pull up a picture ID.
I'm not so sure about the technical merits in the server space, systemd is and will rack up a lot of consulting hours that is good for redhat and others.
Centos picked it up because rhel moved to it, nothing to do with merit only compatibility.
If your starting up a new shop systemd is the path forward because rhel made it that way in the commercial linux space. If your a current shop your moving to it for the same reason. My issue is that is that it is not significantly better. It will generate rhel and others a lot of money and position it better for the desktop/laptop space. Those seems to be the reason commercial linux is moving to it. Ubuntu and the likes it's something new and shiny that is why those distro's exist, support the new stuff compared to the stodgy rhel and the likes.
This argument is similar to the GUI wars on servers, I simply could care less a GUI has no place on a server, if anything it's going to be tunneled down ssh to whatever window manager etc I like to use.
Far better the lack of connection overhead etc means some packets will get through with useful data even with extreme packet loss. Hell it works with total loss of connectivity on the return path (and with properly configured static arp continues to do so). Point being is that some logs is far better than no logs.
Hell we used to build unidirectional ethernet cables for log servers, it's rather hard to leak data to a hacker over an air gap after all.
1 If you don't understand why https is a very poor replacement for syslog over a network that may well be unreliable. I will assume your not really familiar with low level hardware and the failure modes. You do not seem to get the overhead and delay of TCP connections in general and thus why it's a poor choice for logging.
2 Well when your billing T&M there is:), point is reboots should occur so infrequently it does not matter.
3 again no advantage.
4 In your opinion it makes things easier. One text file vs a text file in/etc/sysconfig read in from an init script whats the advantage? Frankly it's just a different templates for the same set of variables in configuration management system, no new functionality is being exposed.
5 So I start SSH and SNMP a few seconds later since the monitoring system is checking them on a regular basis? I'm not seeing any advantage for a server, if your running a service your monitoring a service.
6 Work to setup? Maybe if your just getting started. All this stuff is already been baked into config management systems. systemd just means reworking all that into systemd speak with no great advantage.
7 Outside of service upgrades if I have to restart a service it's broken and needs to be fixed, be that by the vendors or rolling our own if necessary. This is not windows if you have to restart it's broken (mind you I have the same opinion of windows services). So pretty much if you need this your fixing the wrong issue.
8 Systemd fails to give an advantage that is the drawback, something that is new that adds nothing useful in an of itself.
Were just going round and round, systemd fails to do anything new and useful for servers. The pressure to migrate comes from the OS vendors with lots of work and debugging required to get in parity with the current state. So it's effort and time without any improvement for a shop that is already competent and utilizing modern tools. I get that it's got a lot of advantages for laptop/desktops it's just not compelling to server admins. It really should have been an option for rhel7 rather than the default, it's a boon to integration consultants for sure.
OK I'll bite I understand the "tradeoffs" and nothing is rather useful for a server. All the activation based bits sound great for a laptop or even a desktop but are useless on a production server. A prod server should not be running piles of things ssh, a config engine (chef,puppet whatever) and the app. If your app is some ugly pile of services on one box fix it. Take a standard web server stack firewall/IDS, LB, Webserver and DB throw in fast and "slow" object storage, nosql and back end services nothing should be running more than a handful of things.
Lets not even get started into activation based vm start-up. VM players have been trying to sell the whole spool up more web servers during high demand and then reuse that capacity for other things bit for a long time now. It looks great in a PR bit from a sales guy
Sure RH went with it for rhel7 they are are pushing a deskop pretty hard. It's not that it's bad for servers it's just not really bringing anything to the table.
No arrow, function or pretty much anything useful keys, seems like a nightmare.
The perfect keyboard has been around for a long time an IBM M13 mine is nearly 20 years old and in perfect working order. While I like the larger keyboard with f13-24 it's a pita to get many OS's to use them. You can also bludgeon an intruder with it and go back to typing.
Yes the swat teams should be restrained or executed but what to do with the kid? Swatting happens because of police abuse, slap the kid on the wrist for filing a false report or whatever. Make police be civil again the war on drugs has turned them into thugs.
By less you mean the ability to follow ikea level pictures only instructions. Hell the new gen include cellphones that call 911 the instant you pull it off the wall without the override "key" so a dispatcher can walk you though it if needed, the cell phones lets them know where to send help to.
Anything modern is running EDFA's where fiber is doped with Erbium and a pump laser is mixed in they get about 40db of amplification with a 100ma laser. Great part is it's not signal speed dependent as it's an all optical all analog method. The old way was to put a receiver and transmitter coupled back to back used a lot of power and was specific to a speed.
Well you can probably double your density moving to non hot swap 3.5's, making double the drives even on space. Now if I were going to do that I would mirror the raid sets anyways since power consumption of near line drives is pretty minimal.
Never seen much of a use of enterprise sata, I do use a lot of SAS with dual ports to separate raid controllers.
We do just that, when it gets down to 1 hot spare it's an emergency service and we replace all the failed units. This does not happen very often and tends to be just that a bad batch.
Well since they are not supposed to need to be hot swap you can get 12+ drive into a 1ru chassis with redundant power and a fairly beefy server. That is 3x the density of traditional 4 up front 1ru. Expanding to 2ru gives 12 hot swap 3.5's or 24 2.5 still 2x the density in 3.5's for non hot swap. Potentially even higher with 2.5's, though highest I find is 88 hot swaps in a 4ru or 22 per ru coupled with a rather beefy server.
To last all of 4 years, and need nearly as many hot spares as data drives. I guess the academics think they know something yet again. They took some dubious failure rates (backblazes use whatever is the cheapest consumer drive at the time and eventually stop buying the really bad ones (seagate 1.5 and 3tb looking at you)) and a rather optimistic transfer rate (200MBS) that assume all sequential reads. They failed to account for back plane, controller, and power assuming that those never fail. By their numbers you might as well run mirrored raid 5 or 6 with enough hot spares to make it between regularly scheduled tech visits. That give you the ability to split chassis and controllers along mirror lines. As to rebuilds we have better methods, predictive failure works well, ssd's make great caches while rebuilding etc etc. We also have less centralized options with distributed technologies that potentially scale better.
5 9's is not that hard of an objective when talking about raid sets, the tools have been there for decades. Sure you will never reliably reach it with a single path to anything, 5 minutes is not enough time for even a staffed site to remedy any outage.
Incorrect, if they want access to your encrypted information they may get a warrant, you can then defend yourself against said warrant by contesting it, a judge might hold you in contempt for not giving up the keys (that is a contempt to try and make you comply not a punitive one so is only supposed to be until they figure out your not going to). This is not what they seem to be worried about.
They are worried about not being able to just take or use secret courts to access whatever they want. Pervasive encryption means they can no longer get all the info they want from the middle men who tend not to fight back much, use national security letters when even the secret courts wont give them a warrant. Having to use actual warrants served to the people effected who might fight them and use the media to shame them means they better have a good reason vs just fishing. You can also devise hardware and protocols that put a time limit on being able to decypt things that would limit the time held in contempt (simple one is a chip that holds the keys and erases them if it does not get a passcode every so often or looses power a basic extension on existing TMP).
In short you can have secure encryption that the government could force you to let them access. It's messy, time consuming, and does not always work.
MIMO, you can have more than one set of signals without completely interfering.
I doubt that an passive alien race would bother to leave their own gravity well. Hell I doubt a passive species will ever become intelligent int he first place. That said there is little reason for an alien race to care about us, nothing is very useful or unique at the bottom of a gravity well the size of a planet.
It's an issue of population density that is rather curable once we spread out. It's fairly reasonable that they spreading out will keep the aggression in check for a very long time.
You can prove that it effects everybody equally??? That this is no antidote for a select few? You can not ever make that happen. How do you counteract it when an aggressive alien race shows up? Native species becomes dangerous?
Humans need 2 things to thrive, near limitless power and space. Aggression will help us get there, it drives us to risk and to reach.
Look at NASA 60 years ago they strapped a chair to a rocket with less cpu umph that an arduino and made it to the moon. Now they are so worried about any possible failure that it takes them decades to do anything. That is the different between one guy in charge with a mission vs committees upon committees.
Thats just comcast sucking like usual. My optimum linked devices log into comcast routers (transmitting the optimum SSID next to their own) automatically via the sharing agreement they have.
Every comcast, optimum, and others routers are putting out a pile of SSID's and will authenticate via mac address alone. The vast majority of home and small business users end up using whatever the provider gives them.
If they just got our of school, will be working with nobody with more experience than them, and it's a startup with no existing systems, systemd is a great choice for that sort of sysadmins perspective.
Otherwise it fails to give anything compelling useful that could not be done before. It takes a reasonable amount of effort to move to using it with no gain.
At this point security is a basic requirement of all devs, what piece of code does not need at least some semblance of security?
They want you to install an app. Yet pretty much a picture of the barcode is all that is needed. Considering the poor state of security on phones the rights are far to course grained. The app needs to connect to the DMV for authentication means it has access to data at all times. You quickly have a heavily encrypted app that can can expand it's scope of permissions with clueless users.
They will I assume want you to hand your phone to the cop unlocked. Maybe your smart and setup a secondary login with only the licence and insurances apps more probably you handed a cop access to your entire digital life. Is that enough protection to secure the phone from state overreach?
Expand it out will bouncers be able to validate the licence? In effect that means the state knows when you went to what club.
Will potential employers be able to use it? Now the state knows every place you ever applied for a job.
Will stores be able to use it to cash a check (I know how many people will use this that still use checks)
Are fake ID's really a problem primarily it's for buying booze and we along with a handful of other first world nations has the highest legal drinking age in the first world.
What does the phone app add over the existing ability for police to pull up a photo id via the barcode or just name and address on the in cruiser laptops.
How portable will this be one state must accept another's ID. Will they build in the same protections? If so how will they be required to do so and held accountable for failing to do so?
At this point a simple name and address should be all that is needed to pull up a picture ID.
Kids time is already at such a premium.
Fiber works as well :)
I'm not so sure about the technical merits in the server space, systemd is and will rack up a lot of consulting hours that is good for redhat and others.
Centos picked it up because rhel moved to it, nothing to do with merit only compatibility.
If your starting up a new shop systemd is the path forward because rhel made it that way in the commercial linux space. If your a current shop your moving to it for the same reason. My issue is that is that it is not significantly better. It will generate rhel and others a lot of money and position it better for the desktop/laptop space. Those seems to be the reason commercial linux is moving to it. Ubuntu and the likes it's something new and shiny that is why those distro's exist, support the new stuff compared to the stodgy rhel and the likes.
This argument is similar to the GUI wars on servers, I simply could care less a GUI has no place on a server, if anything it's going to be tunneled down ssh to whatever window manager etc I like to use.
Far better the lack of connection overhead etc means some packets will get through with useful data even with extreme packet loss. Hell it works with total loss of connectivity on the return path (and with properly configured static arp continues to do so). Point being is that some logs is far better than no logs.
Hell we used to build unidirectional ethernet cables for log servers, it's rather hard to leak data to a hacker over an air gap after all.
1 If you don't understand why https is a very poor replacement for syslog over a network that may well be unreliable. I will assume your not really familiar with low level hardware and the failure modes. You do not seem to get the overhead and delay of TCP connections in general and thus why it's a poor choice for logging.
2 Well when your billing T&M there is :), point is reboots should occur so infrequently it does not matter.
3 again no advantage.
4 In your opinion it makes things easier. One text file vs a text file in /etc/sysconfig read in from an init script whats the advantage? Frankly it's just a different templates for the same set of variables in configuration management system, no new functionality is being exposed.
5 So I start SSH and SNMP a few seconds later since the monitoring system is checking them on a regular basis? I'm not seeing any advantage for a server, if your running a service your monitoring a service.
6 Work to setup? Maybe if your just getting started. All this stuff is already been baked into config management systems. systemd just means reworking all that into systemd speak with no great advantage.
7 Outside of service upgrades if I have to restart a service it's broken and needs to be fixed, be that by the vendors or rolling our own if necessary. This is not windows if you have to restart it's broken (mind you I have the same opinion of windows services). So pretty much if you need this your fixing the wrong issue.
8 Systemd fails to give an advantage that is the drawback, something that is new that adds nothing useful in an of itself.
Were just going round and round, systemd fails to do anything new and useful for servers. The pressure to migrate comes from the OS vendors with lots of work and debugging required to get in parity with the current state. So it's effort and time without any improvement for a shop that is already competent and utilizing modern tools. I get that it's got a lot of advantages for laptop/desktops it's just not compelling to server admins. It really should have been an option for rhel7 rather than the default, it's a boon to integration consultants for sure.
1 Logs on the server why? Already have real time logging to a different host.
2 If boot times are an issue you failed to build it correctly.
3 same with init
4 Systemd just keys into existing kernel bits, i'ts not providing anything new.
5 SSH and SNMP idle memory/cpu use is trivial balanced against with starting them up every time. I'll take a long running process vs startup time.
6 Again already in existence, it makes it easier to setup but no added function.
7 Yet again nothing new.
8 Init shell scripts are hard? Been writing them for 25+ years. Systemd probably no harder or easier so it's a moot point.
OK I'll bite I understand the "tradeoffs" and nothing is rather useful for a server. All the activation based bits sound great for a laptop or even a desktop but are useless on a production server. A prod server should not be running piles of things ssh, a config engine (chef,puppet whatever) and the app. If your app is some ugly pile of services on one box fix it. Take a standard web server stack firewall/IDS, LB, Webserver and DB throw in fast and "slow" object storage, nosql and back end services nothing should be running more than a handful of things.
Lets not even get started into activation based vm start-up. VM players have been trying to sell the whole spool up more web servers during high demand and then reuse that capacity for other things bit for a long time now. It looks great in a PR bit from a sales guy
Sure RH went with it for rhel7 they are are pushing a deskop pretty hard. It's not that it's bad for servers it's just not really bringing anything to the table.
No arrow, function or pretty much anything useful keys, seems like a nightmare.
The perfect keyboard has been around for a long time an IBM M13 mine is nearly 20 years old and in perfect working order. While I like the larger keyboard with f13-24 it's a pita to get many OS's to use them. You can also bludgeon an intruder with it and go back to typing.
Yes the swat teams should be restrained or executed but what to do with the kid? Swatting happens because of police abuse, slap the kid on the wrist for filing a false report or whatever. Make police be civil again the war on drugs has turned them into thugs.
By less you mean the ability to follow ikea level pictures only instructions. Hell the new gen include cellphones that call 911 the instant you pull it off the wall without the override "key" so a dispatcher can walk you though it if needed, the cell phones lets them know where to send help to.
Anything modern is running EDFA's where fiber is doped with Erbium and a pump laser is mixed in they get about 40db of amplification with a 100ma laser. Great part is it's not signal speed dependent as it's an all optical all analog method. The old way was to put a receiver and transmitter coupled back to back used a lot of power and was specific to a speed.
Ask the AT&T sales guys they know where every strip club that takes amax is.
Well you can probably double your density moving to non hot swap 3.5's, making double the drives even on space. Now if I were going to do that I would mirror the raid sets anyways since power consumption of near line drives is pretty minimal.
Never seen much of a use of enterprise sata, I do use a lot of SAS with dual ports to separate raid controllers.
We do just that, when it gets down to 1 hot spare it's an emergency service and we replace all the failed units. This does not happen very often and tends to be just that a bad batch.
Well since they are not supposed to need to be hot swap you can get 12+ drive into a 1ru chassis with redundant power and a fairly beefy server. That is 3x the density of traditional 4 up front 1ru. Expanding to 2ru gives 12 hot swap 3.5's or 24 2.5 still 2x the density in 3.5's for non hot swap. Potentially even higher with 2.5's, though highest I find is 88 hot swaps in a 4ru or 22 per ru coupled with a rather beefy server.
To last all of 4 years, and need nearly as many hot spares as data drives. I guess the academics think they know something yet again. They took some dubious failure rates (backblazes use whatever is the cheapest consumer drive at the time and eventually stop buying the really bad ones (seagate 1.5 and 3tb looking at you)) and a rather optimistic transfer rate (200MBS) that assume all sequential reads. They failed to account for back plane, controller, and power assuming that those never fail. By their numbers you might as well run mirrored raid 5 or 6 with enough hot spares to make it between regularly scheduled tech visits. That give you the ability to split chassis and controllers along mirror lines. As to rebuilds we have better methods, predictive failure works well, ssd's make great caches while rebuilding etc etc. We also have less centralized options with distributed technologies that potentially scale better.
5 9's is not that hard of an objective when talking about raid sets, the tools have been there for decades. Sure you will never reliably reach it with a single path to anything, 5 minutes is not enough time for even a staffed site to remedy any outage.
Incorrect, if they want access to your encrypted information they may get a warrant, you can then defend yourself against said warrant by contesting it, a judge might hold you in contempt for not giving up the keys (that is a contempt to try and make you comply not a punitive one so is only supposed to be until they figure out your not going to). This is not what they seem to be worried about.
They are worried about not being able to just take or use secret courts to access whatever they want. Pervasive encryption means they can no longer get all the info they want from the middle men who tend not to fight back much, use national security letters when even the secret courts wont give them a warrant. Having to use actual warrants served to the people effected who might fight them and use the media to shame them means they better have a good reason vs just fishing. You can also devise hardware and protocols that put a time limit on being able to decypt things that would limit the time held in contempt (simple one is a chip that holds the keys and erases them if it does not get a passcode every so often or looses power a basic extension on existing TMP).
In short you can have secure encryption that the government could force you to let them access. It's messy, time consuming, and does not always work.