And as a Linux user, I'm very happy about that too.
systemd is completely unapologetically Linux targeted, and made to expose all the cool stuff Linux has but that was getting little use. If it was written in a cross-platform compatible way, there would be no way to guarantee all the functionality would be there always.
audit2allow is an automated rule writer to make usage easier. You're still supposed to use your brain and look at the policy it generates and make sure it's actually sane.
The Oculus Rift CV1 is neat, but still suffers from low resolution. If a 4K headset was available, I would buy it right this minute. The problem is that it would have to be 4K at 90 FPS, which this development solves.
With the huge volumes of data that Google handles, it's probably hard to do any better.
AI style approaches can fail in quite unpredictable ways, and I think Google likely much prefers that too much is blocked than failing to find something obviously fishy but that gets through the algorithm for some obscure reason.
Sometimes simple approaches are the way to go. You're going to have false positives and false negatives no matter what, the question is how much and in what circumstances. And this particularly scenario is unlikely to be all that common.
Because for many orbits, it's easier to launch stuff from the equator.
However, a rocket with no cargo on it and no need to attain orbit can probably launch from anywhere, land in a more optimal location, refuel, attach a satellite, and then launch for real.
The question of course is whether the ability to locate the factory anywhere in the world (eg, next to some useful heavy industry), and not having having size limits due to not having to move the rocket from the factory to the launch pad by land is enough of a benefit to make it worth it.
I have been wondering one related thing: It seems that the Falcon 9 is built just around the maximum size they can manage to move by road.
Now that the rocket has become reusable, could they work around the transport issue by launching the empty rocket from the manufacturing plant and having it land right at the launch pad?
If this is actually viable it could be huge -- build wherever it's most comfortable to build, launch wherever it's most comfortable to launch. I imagine satellites are far easier to ship than the entire rocket, so this might even work to change the launch site to avoid bad weather.
First of all, all those meanings of those ASCII symbols are long obsolete and forgotten. Just because there's a character called "file separator" doesn't mean anybody uses it for any purpose, except perhaps some fossilized piece of software for dealing with tape drives from the 60s.
Second, such an approach would suffer from various problems. For instance you obviously can't use such characters without escape sequences, which means you can't just stick a file in between file separator characters, you've got to process and escape it first, which is inconvenient as hell.
Third, it's generally an inconvenient and annoying way of doing things. Besides escape sequences such a system means you don't know how much memory to allocate in advance, which is annoying to deal with.
Fourth, it's not really suitable for dealing with hierarchical structures and nested pieces of information.
Fifth, it's all a binary mess that's absolutely not self-documenting in any manner, not editable by hand, not humanly understandable without extensive skill with the very specific format, fragile, lacking in validation and error reporting without doing extensive work on that, the list goes on.
Sixth, characteristics like extensibility and backwards compatibility are often very tricky in such formats, and make them full of bizarre hacks for those reasons.
Seventh, all of this stuff requires a lot of specific parsing code that's boring to write and very error prone.
And really, for what gain? If you want something easy and self-documenting, there's JSON. Key-value pairs in plain text are readable and editable by humans, the structure of the data is visible with the unaided eye, it's easy to skip past uninteresting sections, and it's often possible to do useful work with zero documentation.
XML has some features that are well fit for various complicated needs. For instance namespaces allow nesting one document inside another, while DTDs provide a formal definition of what's supposed to go where. Now isn't that neat -- you can write a formal specification than any user, in any language can check a document against without writing thousands of lines of validation logic by hand. XPath allows to make queries against a document -- if you just want to say, extract the title of a document, you don't even need to write code that walks through the structure of it.
XML may be somewhat ugly to the eye and has features that aren't needed for most purposes, but if you need the complication it's far better than some binary mess.
Things like JSON and XML were created because binary formats were an enormous pain in the ass, and because for some uses, the benefits greatly outweigh the inefficiency. In modern times, programmer time is far more expensive than memory, CPU or disk space, so turning a document from a compact 1K of binary data into 32K of human readable text is extremely often a very good tradeoff.
The only loss here is for the Nazis. The site is now harder to access, harder to find, and to boot now it's open season to go and try to hack the site. Tor protects the identity of the user, so now any random hacker wannabe can go and try their skills against the site without much of a risk of being found out.
The same anonymity means it's also far harder for the Daily Stormer from banning people from the site -- unless they want to make it really hard to access, like requiring referrals. So this development also makes it very possible to simply troll and spam the site into oblivion.
I agree that XML is usually insanely overkill for most purposes. Still, there are worse choices than insanely overkill, such as trying to shoehorn a complicated hierarchical data structure into something like TSV, CSV or a fixed length format, as BarbaraHudson seems to be proposing in this discussion.
The parent is talking about.doc and.xls formats. These are absolutely not suitable for something as simple as tab or fixed field formats. They can contain arbitrary data like embedded images and videos. They have a very complex markup system. They have features like versioning, scripts, and oodles of metadata. They have to deal with arbitrary data of arbitrary length. They can attach arbitrary amounts of parameters to some piece of text..doc and similar is one of the few cases where XML is actually not overkill for the task, because XML was made to solve precisely that sort of problem in the first place.
The problem is exchanging tabular and hierarchical data structures, containing arbitrary values.
So for instance the simplest of such structures is a table of id, state, name, description. The description field can of course contain arbitrary characters including quotes, commas and newlines.
Sometimes there's metadata for the table. For instance think of the results of a mysql query: You want a table of the results, but there's also a list of the datatypes of each column, plus the time it took to answer the query.
A more complex one is a directory tree structure, with the usual metadata.
Of course in both cases there's the requirement to be able to add additional fields later, while retaining backwards compatibility.
Do current combustion motors run on hydrogen? Not really.
Are current cars able to contain hydrogen? Not really.
Are current tankers able to transport hydrogen gas? Not really, they're made for a liquid.
Are current gas stations able to dispense hydrogen? Nope, a station's storage, machinery and dispenser nozzle sure as hell aren't made for a gas.
So I'm not seeing much reuse potential here. Now the end-game would look kinda similar to a gasoline infrastructure on the surface, except for the part where you have to replace all the simple tanks and pumps with far trickier pressure vessels and regulators.
Well, let's see the details on what exactly those unsurmountable regulations are. The article contains zero detail on the specifics.
Depending on what Musk intends to do, and where his stuff is going to go, and in what manner, it being unsurmountable may be perfectly reasonable. Or it may be not.
Damn straight permits are needed. Because even the biggest Elon Musk advocate would be screaming bloody murder if they found the Hyperloop would pass right through their living room, their farm, or that really scenic lake on their property.
The question is then what permits, and are they bullshit or not? Some permits exist for obscure reasons, some because some things involve other people's property, some for safety reasons, and some because people get pissy when heavy earth moving equipment shows up in their backyard.
Yes, of course before cities were built and when people were just moving into America, there weren't such problems, because there wasn't a crapload of infrastructure and settled people to object. But you can't have those times back, unless you like the idea of completely unrestrained forfeiture where you can be kicked out of your home to make room for a mall, and companies building housing that's going to sink into the ground in a decade or two.
That seems unlikely to be true. We're constantly making new compounds. I find it hard to believe that all of them, including things we've not invented yet, with the single exception of paracetamol degrade safely.
There's no valid points that are being made here. I finally figured out that all this hubhub is over some random ad NYC posted, and that was probably made by some random intern that just spent a while looking for every gender related term they could find so that it would look as inclusive as possible, and never thought anybody would even think of making a big deal of it.
Somebody just made an ad to say "here we're accepting of everybody, regardless of what you call yourself", and then posted a list of 31 terms, some of which seem duplicates to me (eg, Male-To-Female and MTF both appear in the list, as well as several variations on "trans").
Basically, whoever made that list tried listing absolutely every possible term they could think of just to drive home that point. That's all there is to it. It's like doing the same thing for racism and then filling a page with Wikipedia's list of nationalities.
And this is what people decided to get all outraged about? Sheesh. People have too much free time these days.
And as a Linux user, I'm very happy about that too.
systemd is completely unapologetically Linux targeted, and made to expose all the cool stuff Linux has but that was getting little use. If it was written in a cross-platform compatible way, there would be no way to guarantee all the functionality would be there always.
audit2allow is an automated rule writer to make usage easier. You're still supposed to use your brain and look at the policy it generates and make sure it's actually sane.
No, why would they? Ireland voted against independence because they wanted to stay in the EU. They like it there.
It's going to be great for VR.
The Oculus Rift CV1 is neat, but still suffers from low resolution. If a 4K headset was available, I would buy it right this minute. The problem is that it would have to be 4K at 90 FPS, which this development solves.
With the huge volumes of data that Google handles, it's probably hard to do any better.
AI style approaches can fail in quite unpredictable ways, and I think Google likely much prefers that too much is blocked than failing to find something obviously fishy but that gets through the algorithm for some obscure reason.
Sometimes simple approaches are the way to go. You're going to have false positives and false negatives no matter what, the question is how much and in what circumstances. And this particularly scenario is unlikely to be all that common.
Because for many orbits, it's easier to launch stuff from the equator.
However, a rocket with no cargo on it and no need to attain orbit can probably launch from anywhere, land in a more optimal location, refuel, attach a satellite, and then launch for real.
The question of course is whether the ability to locate the factory anywhere in the world (eg, next to some useful heavy industry), and not having having size limits due to not having to move the rocket from the factory to the launch pad by land is enough of a benefit to make it worth it.
They get carried over public roads as well: https://i.ytimg.com/vi/oNTuSm3...
I remember reading somewhere that the Falcon 9 is just about as big as it can be to still make this possible.
I have been wondering one related thing: It seems that the Falcon 9 is built just around the maximum size they can manage to move by road.
Now that the rocket has become reusable, could they work around the transport issue by launching the empty rocket from the manufacturing plant and having it land right at the launch pad?
If this is actually viable it could be huge -- build wherever it's most comfortable to build, launch wherever it's most comfortable to launch. I imagine satellites are far easier to ship than the entire rocket, so this might even work to change the launch site to avoid bad weather.
I always thought it was a bad idea and never enabled it.
Amazon seems to have really wanted me to enable it, but what's best for Amazon isn't necessarily best for me.
First of all, all those meanings of those ASCII symbols are long obsolete and forgotten. Just because there's a character called "file separator" doesn't mean anybody uses it for any purpose, except perhaps some fossilized piece of software for dealing with tape drives from the 60s.
Second, such an approach would suffer from various problems. For instance you obviously can't use such characters without escape sequences, which means you can't just stick a file in between file separator characters, you've got to process and escape it first, which is inconvenient as hell.
Third, it's generally an inconvenient and annoying way of doing things. Besides escape sequences such a system means you don't know how much memory to allocate in advance, which is annoying to deal with.
Fourth, it's not really suitable for dealing with hierarchical structures and nested pieces of information.
Fifth, it's all a binary mess that's absolutely not self-documenting in any manner, not editable by hand, not humanly understandable without extensive skill with the very specific format, fragile, lacking in validation and error reporting without doing extensive work on that, the list goes on.
Sixth, characteristics like extensibility and backwards compatibility are often very tricky in such formats, and make them full of bizarre hacks for those reasons.
Seventh, all of this stuff requires a lot of specific parsing code that's boring to write and very error prone.
And really, for what gain? If you want something easy and self-documenting, there's JSON. Key-value pairs in plain text are readable and editable by humans, the structure of the data is visible with the unaided eye, it's easy to skip past uninteresting sections, and it's often possible to do useful work with zero documentation.
XML has some features that are well fit for various complicated needs. For instance namespaces allow nesting one document inside another, while DTDs provide a formal definition of what's supposed to go where. Now isn't that neat -- you can write a formal specification than any user, in any language can check a document against without writing thousands of lines of validation logic by hand. XPath allows to make queries against a document -- if you just want to say, extract the title of a document, you don't even need to write code that walks through the structure of it.
XML may be somewhat ugly to the eye and has features that aren't needed for most purposes, but if you need the complication it's far better than some binary mess.
Things like JSON and XML were created because binary formats were an enormous pain in the ass, and because for some uses, the benefits greatly outweigh the inefficiency. In modern times, programmer time is far more expensive than memory, CPU or disk space, so turning a document from a compact 1K of binary data into 32K of human readable text is extremely often a very good tradeoff.
Nope, anybody with the Tor browser can.
The only loss here is for the Nazis. The site is now harder to access, harder to find, and to boot now it's open season to go and try to hack the site. Tor protects the identity of the user, so now any random hacker wannabe can go and try their skills against the site without much of a risk of being found out.
The same anonymity means it's also far harder for the Daily Stormer from banning people from the site -- unless they want to make it really hard to access, like requiring referrals. So this development also makes it very possible to simply troll and spam the site into oblivion.
I agree that XML is usually insanely overkill for most purposes. Still, there are worse choices than insanely overkill, such as trying to shoehorn a complicated hierarchical data structure into something like TSV, CSV or a fixed length format, as BarbaraHudson seems to be proposing in this discussion.
The parent is talking about .doc and .xls formats. These are absolutely not suitable for something as simple as tab or fixed field formats. They can contain arbitrary data like embedded images and videos. They have a very complex markup system. They have features like versioning, scripts, and oodles of metadata. They have to deal with arbitrary data of arbitrary length. They can attach arbitrary amounts of parameters to some piece of text. .doc and similar is one of the few cases where XML is actually not overkill for the task, because XML was made to solve precisely that sort of problem in the first place.
The problem is exchanging tabular and hierarchical data structures, containing arbitrary values.
So for instance the simplest of such structures is a table of id, state, name, description. The description field can of course contain arbitrary characters including quotes, commas and newlines.
Sometimes there's metadata for the table. For instance think of the results of a mysql query: You want a table of the results, but there's also a list of the datatypes of each column, plus the time it took to answer the query.
A more complex one is a directory tree structure, with the usual metadata.
Of course in both cases there's the requirement to be able to add additional fields later, while retaining backwards compatibility.
That doesn't really answer the question I asked.
So what do you recommend instead?
Which is that?
Do current combustion motors run on hydrogen? Not really.
Are current cars able to contain hydrogen? Not really.
Are current tankers able to transport hydrogen gas? Not really, they're made for a liquid.
Are current gas stations able to dispense hydrogen? Nope, a station's storage, machinery and dispenser nozzle sure as hell aren't made for a gas.
So I'm not seeing much reuse potential here. Now the end-game would look kinda similar to a gasoline infrastructure on the surface, except for the part where you have to replace all the simple tanks and pumps with far trickier pressure vessels and regulators.
Well, let's see the details on what exactly those unsurmountable regulations are. The article contains zero detail on the specifics.
Depending on what Musk intends to do, and where his stuff is going to go, and in what manner, it being unsurmountable may be perfectly reasonable. Or it may be not.
Damn straight permits are needed. Because even the biggest Elon Musk advocate would be screaming bloody murder if they found the Hyperloop would pass right through their living room, their farm, or that really scenic lake on their property.
The question is then what permits, and are they bullshit or not? Some permits exist for obscure reasons, some because some things involve other people's property, some for safety reasons, and some because people get pissy when heavy earth moving equipment shows up in their backyard.
Yes, of course before cities were built and when people were just moving into America, there weren't such problems, because there wasn't a crapload of infrastructure and settled people to object. But you can't have those times back, unless you like the idea of completely unrestrained forfeiture where you can be kicked out of your home to make room for a mall, and companies building housing that's going to sink into the ground in a decade or two.
That seems unlikely to be true. We're constantly making new compounds. I find it hard to believe that all of them, including things we've not invented yet, with the single exception of paracetamol degrade safely.
I'm sure they could do at least the takeoff parts in 4K, which is the most spectacular part of it anyway.
I hope they start doing the entire stream in 4K
He does great at sabotaging his own schemes. It's really great that he lacks a filter.
I would love to be a fly on the wall on his lawyers' office. It's got to have a thick covering of hair of all over the floor.
There's no valid points that are being made here. I finally figured out that all this hubhub is over some random ad NYC posted, and that was probably made by some random intern that just spent a while looking for every gender related term they could find so that it would look as inclusive as possible, and never thought anybody would even think of making a big deal of it.
Oh, goddammit. I finally decided to spend sometime to figure out what's all this nonsense about.
It's an ad: https://heatst.com/culture-war...
Somebody just made an ad to say "here we're accepting of everybody, regardless of what you call yourself", and then posted a list of 31 terms, some of which seem duplicates to me (eg, Male-To-Female and MTF both appear in the list, as well as several variations on "trans").
Basically, whoever made that list tried listing absolutely every possible term they could think of just to drive home that point. That's all there is to it. It's like doing the same thing for racism and then filling a page with Wikipedia's list of nationalities.
And this is what people decided to get all outraged about? Sheesh. People have too much free time these days.