Appears it didn't receive any funds since 2022 after being extended for years (so your "daddy" is Biden) and wouldn't get any more money so was canceled to get it off the books.
If anything this shows the list includes regular grants that were canceled for normal reasons, which further demonstrates the cuts were not of real science.
If the default wasn't "almost nothing" then you'd be sanctioning exposing some kids to content their parents didn't want them to see. If there's no economic incentive to tag content then it's not valuable content for kids.
Ultimately the problem is the provider knows what category the content is and the parent knows what the content policy is. Providers can't say whether it's "safe" or "unsafe", only what standards it complies with. Some parents will have weird policies like "only G-rated movies or any Jim Carey movie" that can't even be delegated in any reasonable way to providers.
So the header has "PG-13, US-legal" because it's a movie rated PG-13 and constitutionally-protected legal content in the US, and whatever other markets you want to open up. Providers could even include AI ratings so as to mass-tag their content at low cost, and parents can decide if a particular AI rating is okay.
Parental controls could even restrict official ratings to country of origin, so if you approve PG-13 it'll block that content from countries where you can't sue them for lying about it.
> If there's no economic incentive to tag content then it's not valuable content for kids.
Those two things are completely disjoint. In one case you're measuring the value of the content to the platform and in the other you're measuring the value of the content to the kids.
Suppose there is some content that the platform would get $10 in ad revenue to show to kids, would cost $100 to classify, and is worth $1000 to the kids.
In the land of spherical cows you could have the users pay the money, but that gets killed by transaction costs, privacy issues with payment systems, and that kids generally don't have money. So the kids lose access to valuable information because the platform isn't willing to spend $100 to make $10.
And it's still a problem even if the platform could make as much revenue from showing the content as the user receives value from it. Consider the entire firehose of social media posts on some unspecified site. Classifying it all would cost e.g. a billion dollars. So even if the value of kids having the content was half a billion dollars -- a huge sum equivalent to multiple human lifetimes of labor effort -- to the kids and the platform both, it's not happening because the cost of classifying the content is even larger yet.
> Ultimately the problem is the provider knows what category the content is
That's the problem though. The provider doesn't know what category the content is. There are Wikipedia pages that contain nudity etc. Who is going to pay someone to read the millions of articles and classify each one? But if they instead just mark the whole site as adult content, the amount of non-adult content kids lose access to is large.
The cost to the content provider can be reduced to zero by the parents, by allowing it in parental controls.
So the maximum cost to a provider is capped at convincing parents to disable blocking of the content. That could be an unfathomably large sum for pornhub or negligible for wikipedia.
The question then is what's cheaper, paying to have parents enable the content (for instance advertising to make that choice acceptable) or rating the content? If it's the former that's essentially the same value parents place on blocking that content.
You're looking at rating content in this default-block scheme as a cost, but really it's a discount. You're paying a smaller amount to rate the content "G - general audience" then convincing parents to allow unrated content.
Without section 230 you'd get a few large publishing outlets moderating all content and you'd also get distributed media where the aggregation is done by each individual.
There just wouldn't be that middle area where social media sites get to choose what you are allowed to say or read just because they have a monopoly on the data.
For instance, you could run your own individual Hacker News site that collects the data and creates the same thing you see today - except you could choose to only view posts and comments by sources verified as humans. Or you could turn on 'show dead' on a grander scale - your choice.
> For instance, you could run your own individual Hacker News site
It’s baffling how many people think repealing Section 230 would make it easier for small people to host user-submitted content.
It would do the inverse: It would make hosting user submitted content legally untenable for all but the biggest players with the biggest ad budgets to comply with the laws.
You host your own content, and non-230 telecom rules protect a pure cache so bandwidth and always-on internet needn't be an issue.
It shouldn't be baffling to you; it's not even a hard problem to solve, and the only reason why things like ActivityPub aren't done more today is because of 230. A monopoly on data gives centralized social media an unfair advantage that's only possible through legal immunity.
> You host your own content, and non-230 telecom rules protect a pure cache so bandwidth and always-on internet needn't be an issue.
You can already host your own content. Bandwidth is a non-issue right now.
You’re ignoring, or don’t understand, that the benefit of social media is sharing and distribution. The repeal-230 people always have some fanciful ideas about an alternative system appearing to fill the void and that it will be better for reasons, but the bottom line is that without some protection for services to share content it’s going to be negligible exposure.
Only the few with access and connections to the well-connected large media outlets would have distribution. It would be a total self-own for small people who want to share something.
Some people run their own Mastodon servers, where they share and participate in social media, so there's a proof by example that your fears are unfounded.
You're already responsible for everything you would be on a private server (one user). If you go to 8chan and see illegal content then good luck telling the authorities you're not responsible because it's 'just' in your browser cache.
Wouldn't just good screen sharing solve your coffee table problem?
Just have the coffee table iPad be a display for your own iPad. You could even have a virtual iPad on your mac that you show on the coffee one if you don't have your own.
MacOS has 'high-performance' screen sharing using hardware encoder/decoder now. Windows has had this for years and it's so fast it's like actually using the remote computer. It's not like old-school VNC, the only real functional drawback is that you can't leave wifi range.
Seems reasonable that an alien craft travelling between stars might want to illuminate the whole star system to detect dark objects and plot a safe or more perfect course.
Apparently Wow! came from the same area and seemingly was blue-shifted by an amount that could make sense from an approaching craft, so that doesn't sound that silly to me.
> and seemingly was blue-shifted by an amount that could make sense from an approaching craft
What do you think the natural spectrum of the Wow signal was, for determining amount of blue shift? What resolution of spectral data do you think we have on it?
Wikipedia Wow! article says it is equivalent of hydrogen line plus 10 km/s blue shift.
Even if this was a scanning beam I think we can assume it would take a lot of energy and so may be based on a simple scalable physical process. Using hydrogen to create it makes sense as it is low mass and can be replenished.
It seems more likely that it'll act like a non intelligent hunk of rock going through some random trajectory.
It's less silly to declare you'll win the lottery. That has happened many times over - but we're yet to discover that can or has existed outside of Earth. While it's nearly impossible it hasn't happened several times over, it's so far impossible that we've encountered even the crumbiest excuse for life.
I assert that it is silly. We're not indigenous American happening upon European settlers. We're indigenous Americans wandering about the continent harassing mammoths, inventing stories of how it'll go when it happens.
A ship approaching a sun will see the objects on the far side illuminated fully, but objects on the near side will be illuminated only on a thin edge, like a crescent moon, because they're looking at the 'back' side of the objects.
By sending out a pulse of light they could not just light up the ship-facing side of objects but also determine their precise location and velocity. Seems like something you'd want to do to not waste your thousand-year mission by accidentally colliding with a dark object.
The Wow! signal could be just such an event.
Aliens might use some type of scanning beam rather than a big flash, but I doubt we have the 1977 data to differentiate between a beam scanning our area and a solar-system-wide flash.
Would this be far enough out to use the sun's gravitational lensing to image distant planets?
It seems like the idea was to send a bunch of instruments way out and then take pictures in the brief time they were at a useful distance, but if there's a planet out there we can orbit and so stop the instruments at that distance it seems like we could make a permanent super telescope.
orbiting a planet in that case is no different than orbiting a sun on the same orbit as planet. Probably even more cumbersome, all that jiggling around. Or are you talking about making a gravity assist to turn the orbit of the probe into less eccentric?
I'd like to remind you that there are still millions of people around the world using Windows 7 daily. The fact that some software is no longer supported by its developer doesn't mean it stops working somehow, or becomes radioactive.
You can't really exploit something when its attack surface is nearly nonexistent, which is the case for most people who use an outdated OS on their personal device, for example.
Even if there's an exploitable vulnerability, the exploit has to be delivered to the target system somehow. You don't have much of an opportunity to do that with a device that doesn't have a public IP address. Most likely the user themselves will have to do something that would compromise their system, like visiting a website that would serve them an exploit for their particular combination of browser and OS.
For example, when solar plus direct air capture can remove a ton of CO2 for cheaper than it costs a container ship not to emit that CO2 then it's reduced cost for the same CO2 outcome even though it's using more total energy.
Regardless of whether it actually makes sense to capture carbon, you'll see a lot of sky-is-falling fanatics and vested interests dismissing it because it caps the price of carbon credits and limits economic damage estimates. You can't price CO2 at $500/ton to necessitate change when it only costs $200/ton to capture it - without quickly going bankrupt that is.
This is why the IPCC not even attempting to evaluate mechanical capture shows they aren't serious about solving the problem. They seemingly exist to push a fear narrative, and having an upper bound on the impact of CO2 limits their ability to do so.
The 1..125 loop stores 8000 bytes of string and they need to clear 8000 bytes.
There may be a fast path for adding one character, but in any case bytes of program are a valuable resource with only 64k ram so having a second loop from nearest power of two to 8000 would be a waste of bytes.
If this had been in shells and cmdline tools since the beginning it would have saved so much work, and the security problems could have been dealt with by an eval that only set variables, adding a prefix/scope to variables, and so on.
Unfortunately it's too late for this and today you'll be using a pipeline to make the json output shell friendly or use some substring hacks that probably work most of the time.
That's great for key=value data, but more complex data structures don't work so well in that format, JSON does. "Why would you need to represent data as a complex data structure?" Sometimes attributes are owned by a specific entity, and that entity might own multiple attributes. It might even own other sub-entities. JSON represents that. Key=value does not.
JSON is literally key=value, just nested. Which you can do with shell variables.
The question was "What's not to like [about JSON output from cmdline tools]?" and the answer is that it's cumbersome to read in a shell and all but requires another pipeline stage.
I didn't even recommend shell variable output and made it clear this isn't today a reasonable solution so I'm not sure where this hostility in the replies comes from, but I assume from recognition that it's a more practical solution to reading data within a shell but not wanting that to be so.
The nature of being nested, and also containing structures like lists, maps, etc. All of which makes it more complicated than key=value.
> The question was "What's not to like [about JSON output from cmdline tools]?" and the answer is that it's cumbersome to read in a shell and all but requires another pipeline stage.
It depends on the intended use for your shell program. If you intend the CLI tool to be used in CI pipelines (eg. your CLI tool's output is being read by an automated process on a computer) and the data it outputs is more complicated than a simple key=value, JSON is great for that. Your CI program can pipe to jq. You as a human can pipe to jq, though I agree it's somewhat less desirable. Though just piping to jq without any arguments pretty prints it for you which also makes it fairly readable for humans.
> so I'm not sure where this hostility in the replies comes from
You're reading into hostility where there isn't any.
> The nature of being nested, and also containing structures like lists, maps, etc. All of which makes it more complicated than key=value.
These are javascript objects, which are key-value. A list array is just keyed by a number instead of a string. They're functionally exactly the same as name=value except JSON is parsed depth-first whereas shell variables are breadth-first parsing (which is way better from shells).
Do you have an example of a CLI tool - intended for human use - that has output so complicated it can't be easily mapped to name=value? I don't think there is one, and it's certainly not common.
> You're reading into hostility where there isn't any.
I think "it seems you're determined not to use jq" is pretty hostile since I made no intimation of that at all.
> I think "it seems you're determined not to use jq" is pretty hostile since I made no intimation of that at all.
Well, I didn't say that, so I don't know what that other person's feelings or intentions are, to be fair. I personally have no feeling of hostility towards you just because we (apparently) disagree on the usefulness of JSON to represent complex data types, or at least disagree on how often human-usable CLI tools output complex data. But to answer:
> Do you have an example of a CLI tool - intended for human use - that has output so complicated it can't be easily mapped to name=value? I don't think there is one, and it's certainly not common.
kubectl. Which to be fair defaults to output to a table-like format. Though it gets all that data in the table from JSON for you.
smartctl is another one, which also defaults to table format.
To be honest, I could go on and on if the only qualifier is a CLI tool that emits complex data, not suited for just key=value.
> These are javascript objects, which are key-value. A list array is just keyed by a number instead of a string. They're functionally exactly the same as name=value except JSON is parsed depth-first whereas shell variables are breadth-first parsing (which is way better from shells).
As mentioned before, just because you can compare JSON to key=value, does not mean it's as simple as key=value. It's a data serialization language that builds well on top of simple key=value formats. You're welcome to enjoy other data serialization languages, like yaml, HCL, or PKL. But none of those are simple key=value formats either. They built the ability to represent more complex structures on top of that.
A data serialization language allows the end-user to specify how they would like to use that data, while allowing them to use standard parsing tools like jq. Cramming complex data into a value string in a key=value format gives end users the same allowance to use that data however they want, while also giving them a chore to handle parsing it in custom ways tailored to just your CLI application, likely in ways that would seem far more brittle than parsing a defined language with well defined constraints. That doesn't sound like great UX to me. But to be fair to you, you're not saying that you wish to use key=value to represent complex data. Rather, you're saying there's a general lack of complex data to be found, to which I also disagree with.
> But none of those are simple key=value formats either.
What is the difference between:
{ object: { name: value }}
{ object: "{ name: value }"}
object="name=value"
There's zero difference between any of them except how you parse and process the data.
> kubectl. Which to be fair defaults to output to a table-like format.
With line-based shell-variable output you have a line of variables and you have blocks of lines separated by an empty line (like an HTTP 1 header).
This can easily map to any table, two dimensions, or two levels of data structure without even quoting subvariables like in the example above. So, no, kubectl is not an example at least not how you've described it.
> What is the difference between .. There's zero difference between any of them except how you parse and process the data.
Answered in the previous message... "A data serialization language allows the end-user to specify how they would like to use that data, while allowing them to use standard parsing tools like jq. Cramming complex data into a value string in a key=value format gives end users the same allowance to use that data however they want, while also giving them a chore to handle parsing it in custom ways tailored to just your CLI application, likely in ways that would seem far more brittle than parsing a defined language with well defined constraints."
> With line-based shell-variable output you have a line of variables and you have blocks of lines separated by an empty line (like an HTTP 1 header)...
I would not choose to write application logic that foregoes defined data serialization languages for parsing barely structured strings the way you seem to prefer. But you go about it the way you prefer, I guess. This whole discussion leaves a lot of room for personal opinions. I think we both agree that the other person's opinion here is subjectively the more annoying route to deal with. But that's the way life is sometimes.
That's not your original request though, to use line-based data. It seems you're determined not to use jq but if anything, json output | jq is more the unix way than piping everything through shell vars.
> That's not your original request though, to use line-based data.
It wasn't my request and OP (not me) said "line-based data" is best. The comment I replied to said "Newline-delimited JSON ... a line-based format".
If the only objection you have is "but that's line-based!" then you're in a completely different conversation.
> if anything, json output | jq is more the unix way than piping everything through shell vars.
The unix way is line-based. The comment I replied to is talking about line-based output. Line-based output is the only structure for data universal to unix cmdline tools - even tab/space isn't universal; sending structured non-line-delimited data to a program to unpack it is the least unix-like way to do it.
Also there's no pipe in the shell-variable output scheme I described, whereas "json | jq" is a shell pipeline.
And, the author isn’t suggesting only having JSON output, but adding it as an option for those of use that would make use of it. The plain text should remain as well (and has to or many, many things would break).
On a separate point, I find the JSON much easier to reason about. The wall of text output doesn’t work for my brain - I just can’t see it all. Structuring/nesting with clear delineations makes it far easier for me to grok.
Appears it didn't receive any funds since 2022 after being extended for years (so your "daddy" is Biden) and wouldn't get any more money so was canceled to get it off the books.
If anything this shows the list includes regular grants that were canceled for normal reasons, which further demonstrates the cuts were not of real science.
reply