Yes. That is how it "should" be! So why then did the contract on my new Ford Focus I bought direct from them a while back run 36 pages of impenitrable legalese?
Irrelevant because thats not what this story is about. There is a reason for the 36 pages of legalese, but in this case the customer didnt hit line 1: pay your bill. You can argue policy and how evil they are all day long, but not being able to meet a financial obligation when someone has a claim to your vehicle is a really good way to lose your vehicle.
An average person could not possibly comprehend the terms of a normal loan agreement
Then dont agree to it. In general if you dont understand a contract or the obligations that will be placed on you, it is incredibly foolish to agree to them.
But in this case it isnt even that complicated; the terms that people arent meeting is "pay your monthly bill". What about that part is hard?
Look im not saying predatory loans dont suck, but this is the real world and there are nasty people out there. Theres noone who can protect you from yourself if youre gonna sign all sorts of financial agreements that you cant meet.
They shouldnt be legal, and people are being preyed upon.
But at the same time people need to take some responsibility, use their brain, and stop taking on additional debt when they're deep in the hole. Some of the comments in this thread are truly scary; I wonder how many of you are deep in debt because of these approaches to finance, and it makes me sad. I think of all the student debt that people have that they could have avoided with a sensible degree from a in-state school, and all of the car debt from people who could have bought used (as you suggested).
Predatory lenders share some of the blame here absolutely, but people really need to wake up to how dangerous debt is.
I cant believe the degree to which blame shifting is happening in this thread. How about you meet your financial obligations, or dont take out loans you cant afford?
When you park illegally and they boot your car, do you then complain that you werent able to pick up your sick diabetic daughter from chemotherapy? Or do you have a moment of introspection and ask, "how did I screw up in this situation, and how can I do better?"
Wild thought here, but how about not taking out loans if you cant make the payment? Do we need to review what a loan is?
" a worse option for the poor than "let your family starve while you scrounge up money".:-/
Generally speaking noone starves (preventably) in the US. The number is not tracked as an independent stat, and generally those who do starve fall into high risk groups like the elderly and infants.
There are so many aid programs that you can not work and not be anywhere near starvation.
Its affected because of bash, which is distinct from the kernel. Likewise heartbleed was a problem on linux because of OpenSSL, and not Windows because Windows uses sChannel.
As I said-- legit kernel flaws are super rare. 99% of viruses these days come in through browsers (20%) and their plugins (80%). Attacks on servers tend to be through the http or ssl daemons or associated extensions (php etc).
The NIST page indicates that DHCP could be used to exploit it. It also indicates low complexity and no authentication required, so Im not convinced youre correct.
Looking at security discussions in terms of OS is really, really dumb. Windows wasnt vulnerable to heartbleed or this, but not because its Windows. Linux isnt affected because of the kernel. As has been the case for a very long time, actual OS flaws are exceedingly rare.
Anyone who uses this as an opportunity to post a screed about how Linux is better or worse than Windows is showing their ignorance by boiling down complex security considerations into black and whites.
Thats a fine criticism to make ("its not stable enough-- run it thru Ubuntu / Fedora / whatever for more cycles"), and its not where my issue lies.
My issue lies when people who are supposedly system administrators-- whom one would hope knew their IT fundamentals-- start raising objections that make no actual sense, like the problem with a binary format simply because its a binary format. Thats not a valid objection: all formats are binary formats, and all of them were at one point new. You can say "it needs more testing" (as you did), but at some point it will be tested, and at that point continuing to object on the grounds that its binary as if that fact somehow makes it less reliable begins to reveal a fundamental misunderstanding of how computers and data work.
What's really being expressed here is "the tools and conventions I use are being changed, and thats scary-- therefore it must be bad." Change CAN be bad, and its never much fun, but it can often be beneficial. I wonder if you compared a simple filesystem like FAT to one with journalling and checksumming like ZFS, if you might be able to complain about the arcane data structures and metadata and checksums used by ZFS compared to the simple FAT. But noone sane would argue that FAT is more reliable or more desirable for production systems, and its not a problem: the filesystem is well documented and has multiple well vetted OSS implementations, so it doesnt much matter that your Mac or Windows box wont be able to read it.
Its interesting that in the Debian bug where one of the massive discussions happened, "binary log" (or logs, or logging, etc) only occurs in 2 people's posts (and in one quote)-- this in a thread with some ~8000 comments (try ctrl-f'ing if yourself-- "binary L"). I wonder if thats because the devs there understand that whatever issues systemD has, the "binaryness" of its logs just isnt one.
I wasnt arguing systemD was good (as thats outside of my area of expertise, being primarily a networking / virtualization / storage guy).
Im just saying everyone's objection that "its binary" as they type away on a digital computer with digital storage and a digital processor is several kinds of hilarious. The "text" distinction is an end-user one only; when you're dealing with system recovery and troubleshooting scenarios you put the abstractions away and deal with reality (its all binary).
Theres no such thing as a "text" datatype on computer systems. Every piece of data in your computer is binary.
The people in this thread are blowing my mind with their ignorance and / or obstinance.
Mysql is for people who occassionally like to use data, so funny you picked that for example.
My statement applies to all database systems, you gonna mock those too? Perhaps you could drop google or microsoft a line and let them know about your new, non-binary computer data storage system.
You are very funny. If a machine is stalled in booting do you have tool available to read specialized binary file, versus those needed to list a text file?
In your scenario you are positing that you have the ability to run binaries (like cat or vim or nano)-- the tools required to successfully read and parse ASCII files. Why are you assuming you would be unable to use another binary dedicated to reading and parsing a binary log file?
There is NOTHING magical about ASCII except that its an old standard. At some point it was a new standard, and EVERY SINGLE OBJECTION being made here could have been made about ASCII. If you could examine the disk surface and successfully decode the logs, then you would have a valid objection-- but "text" or "binary", you need a working filesystem and the ability to execute commands to parse logs. It makes NO DIFFERENCE.
yes there is a difference, a human can read a text file with no special tools,
Either you're not getting me or you dont understand what ASCII is.
You are using a "special tool" when you use vim or cat to parse a log file. At some point someone made the decision to start storing data on the disk, even though it was in this "scary" binary format called ASCII that you keep referring to as text. People store million dollar data in binary formats called SQL records. Its absurd that sysadmins balk at the idea of storing binary data in an encoding that happens not to be ASCII, just because its not ASCII.
Speaking of pseudo-intellectualism you need to take a step back and realize that this objection holds no water. The fact that systemD is becoming a standard and that all systems with it have the tools to parse it means nearly any system you attempt to do a recovery from will also have the tools to parse the log. Whats next, complaining about ASCII because its not EBCDIC and is thus a scary binary format with few tools to parse it? We'd be still stuck on punch cards if everyone had taken this "change is scary" attitude.
And everyone including you is pretending that theres a categorical difference between binary data and text. Only at a very high level of abstraction could you find a qualitative difference between "text" (aka arrays of ASCII-encoded bytes) and binary (which can be formatted in a zillion ways). It makes absolute sense when talking to laypersons; but when you speak of system recovery and which is "more reliable" you fly off the deep end, because--again-- there is not a qualitative difference between the two.
People use wireshark just fine despite it all being "binary"; it works because wireshark can dissect and decode the binary, because it is standardized and well formatted. Why would you suppose systemd logging to be any different? Would you suggest wireshark operate on ASCII structures rather than the raw binary?
Its like people are attempting to argue that rectangles are better than squares. I've got news for you...
Thats not actually true, though it could be if you hit all of the tax incentives. Even at 10k income you're still getting some tax (though again, there are probably a lot of ways to reduce the burden to $0).
Except that the vast majority of the population is NOT in population centers, but spread across the surface area.
Nukes also have an easier time leveling buildings than they do utterly decimating populations. The fireball generally is very small, the overpressure that will kill you is a bit bigger, but theres a wide zone of "buildings become unsound" where people suffer much lesser effects.
You're right that it would screw up civilization, but only for a bit. WW2 wrecked a LOT of countries, but they did bounce back because people dont tend to sit amidst rubble going "what do we do now"-- they tend to rebuild society.
I think his point is that an ASCII log is human readable with any text editor without needing an interpreter program.
And that is 100% wrong. Text files in ASCII are still binary, they just conform to a standard that uses 7 bits per character and has a character map that corresponds to written text. At the end of the day it is a stream of 1s and 0s like any other binary file. Executable code, too, is a stream of 1s and zeros that corresponds to certain glyphs, but they happen to be glyphs that are meaningful to a processor rather than to a human.
Whats crucial to really understand here is that there isnt a difference of kind here; everyone seems to be over-abstracting things to where they have some hard barrier between what makes something "binary" vs "text". The only reason we are "comfortable" with text is because there is a very wide variety of interpreters that can display ASCII in a human readable form on screen; but when you boil it down there isnt an actual qualitative difference between that and a particular record in a SQL table other than the programs that interact with that data.
Slashdot Mirror
Yes. That is how it "should" be! So why then did the contract on my new Ford Focus I bought direct from them a while back run 36 pages of impenitrable legalese?
Irrelevant because thats not what this story is about. There is a reason for the 36 pages of legalese, but in this case the customer didnt hit line 1: pay your bill. You can argue policy and how evil they are all day long, but not being able to meet a financial obligation when someone has a claim to your vehicle is a really good way to lose your vehicle.
An average person could not possibly comprehend the terms of a normal loan agreement
Then dont agree to it. In general if you dont understand a contract or the obligations that will be placed on you, it is incredibly foolish to agree to them.
But in this case it isnt even that complicated; the terms that people arent meeting is "pay your monthly bill". What about that part is hard?
Look im not saying predatory loans dont suck, but this is the real world and there are nasty people out there. Theres noone who can protect you from yourself if youre gonna sign all sorts of financial agreements that you cant meet.
They shouldnt be legal, and people are being preyed upon.
But at the same time people need to take some responsibility, use their brain, and stop taking on additional debt when they're deep in the hole. Some of the comments in this thread are truly scary; I wonder how many of you are deep in debt because of these approaches to finance, and it makes me sad. I think of all the student debt that people have that they could have avoided with a sensible degree from a in-state school, and all of the car debt from people who could have bought used (as you suggested).
Predatory lenders share some of the blame here absolutely, but people really need to wake up to how dangerous debt is.
too risky for someone to give me a loan
Absolutely right, and in that situation you shouldnt even glance at a loan.
Is this a predator because they are selling me a car when noone else will?
Could be, if theyre giving loans they know you cant repay and shouldnt be taking (which is the situation you're describing).
I cant believe the degree to which blame shifting is happening in this thread. How about you meet your financial obligations, or dont take out loans you cant afford?
When you park illegally and they boot your car, do you then complain that you werent able to pick up your sick diabetic daughter from chemotherapy? Or do you have a moment of introspection and ask, "how did I screw up in this situation, and how can I do better?"
Wild thought here, but how about not taking out loans if you cant make the payment? Do we need to review what a loan is?
" a worse option for the poor than "let your family starve while you scrounge up money". :-/
Generally speaking noone starves (preventably) in the US. The number is not tracked as an independent stat, and generally those who do starve fall into high risk groups like the elderly and infants.
There are so many aid programs that you can not work and not be anywhere near starvation.
I'd be interested to see how you could ever prove that a historical SSL connection was MITM'd by someone who had your private key.
Its affected because of bash, which is distinct from the kernel. Likewise heartbleed was a problem on linux because of OpenSSL, and not Windows because Windows uses sChannel.
As I said-- legit kernel flaws are super rare. 99% of viruses these days come in through browsers (20%) and their plugins (80%). Attacks on servers tend to be through the http or ssl daemons or associated extensions (php etc).
The NIST page indicates that DHCP could be used to exploit it. It also indicates low complexity and no authentication required, so Im not convinced youre correct.
Looking at security discussions in terms of OS is really, really dumb. Windows wasnt vulnerable to heartbleed or this, but not because its Windows. Linux isnt affected because of the kernel. As has been the case for a very long time, actual OS flaws are exceedingly rare.
Anyone who uses this as an opportunity to post a screed about how Linux is better or worse than Windows is showing their ignorance by boiling down complex security considerations into black and whites.
Heartbleed exploits were and will continue to be generally undetectable. If any private keys were stolen, we wont ever know.
Thats a fine criticism to make ("its not stable enough-- run it thru Ubuntu / Fedora / whatever for more cycles"), and its not where my issue lies.
My issue lies when people who are supposedly system administrators-- whom one would hope knew their IT fundamentals-- start raising objections that make no actual sense, like the problem with a binary format simply because its a binary format. Thats not a valid objection: all formats are binary formats, and all of them were at one point new. You can say "it needs more testing" (as you did), but at some point it will be tested, and at that point continuing to object on the grounds that its binary as if that fact somehow makes it less reliable begins to reveal a fundamental misunderstanding of how computers and data work.
What's really being expressed here is "the tools and conventions I use are being changed, and thats scary-- therefore it must be bad." Change CAN be bad, and its never much fun, but it can often be beneficial. I wonder if you compared a simple filesystem like FAT to one with journalling and checksumming like ZFS, if you might be able to complain about the arcane data structures and metadata and checksums used by ZFS compared to the simple FAT. But noone sane would argue that FAT is more reliable or more desirable for production systems, and its not a problem: the filesystem is well documented and has multiple well vetted OSS implementations, so it doesnt much matter that your Mac or Windows box wont be able to read it.
Its interesting that in the Debian bug where one of the massive discussions happened, "binary log" (or logs, or logging, etc) only occurs in 2 people's posts (and in one quote)-- this in a thread with some ~8000 comments (try ctrl-f'ing if yourself-- "binary L"). I wonder if thats because the devs there understand that whatever issues systemD has, the "binaryness" of its logs just isnt one.
I wasnt arguing systemD was good (as thats outside of my area of expertise, being primarily a networking / virtualization / storage guy).
Im just saying everyone's objection that "its binary" as they type away on a digital computer with digital storage and a digital processor is several kinds of hilarious. The "text" distinction is an end-user one only; when you're dealing with system recovery and troubleshooting scenarios you put the abstractions away and deal with reality (its all binary).
Theres no such thing as a "text" datatype on computer systems. Every piece of data in your computer is binary.
The people in this thread are blowing my mind with their ignorance and / or obstinance.
Mysql is for people who occassionally like to use data, so funny you picked that for example.
My statement applies to all database systems, you gonna mock those too? Perhaps you could drop google or microsoft a line and let them know about your new, non-binary computer data storage system.
You are very funny. If a machine is stalled in booting do you have tool available to read specialized binary file, versus those needed to list a text file?
In your scenario you are positing that you have the ability to run binaries (like cat or vim or nano)-- the tools required to successfully read and parse ASCII files. Why are you assuming you would be unable to use another binary dedicated to reading and parsing a binary log file?
There is NOTHING magical about ASCII except that its an old standard. At some point it was a new standard, and EVERY SINGLE OBJECTION being made here could have been made about ASCII. If you could examine the disk surface and successfully decode the logs, then you would have a valid objection-- but "text" or "binary", you need a working filesystem and the ability to execute commands to parse logs. It makes NO DIFFERENCE.
yes there is a difference, a human can read a text file with no special tools,
Either you're not getting me or you dont understand what ASCII is.
You are using a "special tool" when you use vim or cat to parse a log file. At some point someone made the decision to start storing data on the disk, even though it was in this "scary" binary format called ASCII that you keep referring to as text. People store million dollar data in binary formats called SQL records. Its absurd that sysadmins balk at the idea of storing binary data in an encoding that happens not to be ASCII, just because its not ASCII.
Speaking of pseudo-intellectualism you need to take a step back and realize that this objection holds no water. The fact that systemD is becoming a standard and that all systems with it have the tools to parse it means nearly any system you attempt to do a recovery from will also have the tools to parse the log. Whats next, complaining about ASCII because its not EBCDIC and is thus a scary binary format with few tools to parse it? We'd be still stuck on punch cards if everyone had taken this "change is scary" attitude.
Thats not a powershell vulnerability, its a piece of malware written in Powershell.
What you said would be like claiming C++ exploits because many viruses are written in C++.
Correction-- should have been "argue that squares are better than rectangles".
And everyone including you is pretending that theres a categorical difference between binary data and text. Only at a very high level of abstraction could you find a qualitative difference between "text" (aka arrays of ASCII-encoded bytes) and binary (which can be formatted in a zillion ways). It makes absolute sense when talking to laypersons; but when you speak of system recovery and which is "more reliable" you fly off the deep end, because--again-- there is not a qualitative difference between the two.
People use wireshark just fine despite it all being "binary"; it works because wireshark can dissect and decode the binary, because it is standardized and well formatted. Why would you suppose systemd logging to be any different? Would you suggest wireshark operate on ASCII structures rather than the raw binary?
Its like people are attempting to argue that rectangles are better than squares. I've got news for you...
A sysadmin, but doesnt know what fundamental datatype strings are stored as or what ASCII is?
What is the world coming to :(
And good lord have you ever heard of mySQL? I hear thats binary too!
PST, its all binary.
If youre gonna post strawmen, anonymous is probably the way to go.
What I've generally seen is calls to cut the hyperbole in half and accept Fukushima for what it is.
Thats not actually true, though it could be if you hit all of the tax incentives. Even at 10k income you're still getting some tax (though again, there are probably a lot of ways to reduce the burden to $0).
Except that the vast majority of the population is NOT in population centers, but spread across the surface area.
Nukes also have an easier time leveling buildings than they do utterly decimating populations. The fireball generally is very small, the overpressure that will kill you is a bit bigger, but theres a wide zone of "buildings become unsound" where people suffer much lesser effects.
You're right that it would screw up civilization, but only for a bit. WW2 wrecked a LOT of countries, but they did bounce back because people dont tend to sit amidst rubble going "what do we do now"-- they tend to rebuild society.
I think his point is that an ASCII log is human readable with any text editor without needing an interpreter program.
And that is 100% wrong. Text files in ASCII are still binary, they just conform to a standard that uses 7 bits per character and has a character map that corresponds to written text. At the end of the day it is a stream of 1s and 0s like any other binary file. Executable code, too, is a stream of 1s and zeros that corresponds to certain glyphs, but they happen to be glyphs that are meaningful to a processor rather than to a human.
Whats crucial to really understand here is that there isnt a difference of kind here; everyone seems to be over-abstracting things to where they have some hard barrier between what makes something "binary" vs "text". The only reason we are "comfortable" with text is because there is a very wide variety of interpreters that can display ASCII in a human readable form on screen; but when you boil it down there isnt an actual qualitative difference between that and a particular record in a SQL table other than the programs that interact with that data.