didroe

It's the exact same training process for both of your examples. I don't really see how you can claim books are not replicated, but that output from other LLMs is.

They have no choice but to train their own model to try and survive. They're paying API pricing for the top tier models but competing against subsidized subscriptions.

The problem is, what's ambiguous or precise is subjective. Your devil's advocate needs to reflect all of the possible readers, and that isn't possible.

There's a good reason we use jargon in professions, or more constrained and less ambiguous languages for maths/coding

The problem is that evolution works on a much longer timescale than the pace of change to the environment that humans cause.

With RL, models no longer just learn what sounds correct based on patterns they've seen. They learn what words to output to be correct. RL is the process of forcing the pre-trained weights to be logically consistent.

How does Reinforcement Learning force the weights to be logically consistent? Isn't it just about training using a coarser/more-fuzzy granularity of fitness?

More generally, is it really solving the task if it's given a large number of attempts and an oracle to say whether it's correct? Humans can answer the questions in one shot and self-check the answer, whereas this is like trial and error with an external expert who tells you to try again.

The underlying feature of FIAT money creation is debt. And debt is a very natural thing (existing before money) that will just manifest in the crypto system instead.

How do you know it's safe to redeploy? If your entire operation may be compromised, how can you trust the code hasn't been modified, that some information the attackers have doesn't present a further threat, or that flaws that allowed the attack aren't still present in your services? It's a large company so likely has a mess of microservices and outsourced development where no-one really understands parts of it. Also, if they get compromised again it would be a PR disaster.

They're probably having to audit everything, invest a lot of effort in additional hardening, and re-architect things to try and minimise the impact of any future attack. And via some bureaucratic organisational structure/outsourcing contract.

That's the definition of a "reference pixel", not a pixel. They actually refer to a pixel (and the angle) in the definition.

In the UK and Ireland (and maybe elsewhere?), a kettle lead is actually C13. I guess you need a beefier cable/pins in the US, as you're drawing more current at a lower voltage.

Most kettles now have a base with an integrated cable though, so the name doesn't really correspond with the cable's most common usage any more.

local reasoning everywhere via lazy evaluation

Doesn't lazy evaluation mean memory/complexity issues could manifest far away from the problematic code?

The rules do work on the AST but the current cookie rule is not as advanced as it could/should be. For example, we really should treat encryption as sanitizing the value.

We'll take another look at the rules with this in mind. If you are able to share the (rough) approach you take to build the cookie string it would help us to ensure we're covering the specific case(s) you have.

Thanks for your questions. Yes we do perform dataflow analysis:

1. Not yet but we are exploring ways to support that

2. The analysis part is sound. False +ves (mainly) come from limitations with what you can specify in the rule language. We're working on this however.

3. We don't make that distinction in the rules language currently. Sensitive data detection (which is built-in) is effectively treated as a source. But we need to allow rules to specify sources. I don't think the limitation matters to finding issues, but more to how well they are reported (you effectively only get the sinks reported at the moment).

4. We plan to add other languages but are mindful of the balance of depth vs breadth of support. Is there a particular language you'd like to see support for?

5. There is no support for these currently unfortunately.

6. As it's intra-procedural, we take quite a basic approach to these (with some special cases in the engine). In terms of dataflow, we treat unknown function calls as identity functions (assume the output is somehow influenced by all the inputs). Obviously this is not ideal in terms of false +ves, but we need to work on inter-procedural support first to do a good job of this. In terms of type analysis, we will try to infer unknown types locally from field/property access.

But this technology does enable something novel. Digital self-custody of scarce assets is a new thing.

It's unfortunately also pretty much pointless. Digital assets aren't scarce, and physical assets mean leaving the system and losing the properties of it.

If you're going to use a different currency, why not just use USD or EUR?

The main advantages of Ruby blocks over that approach are:

- they have special control flow that interacts with the method call or surrounding function. ie. calling `break` in `something` can early return from `someMethod`, or calling `return` will return from the function containing the `someMethod` call (blocks use `next` to return from them)

- due to using separate syntax / being a separate language construct, there is far better ergonomics in the presence of vargs or default values

Take this contrived example for instance:

  def some_method(a = 42)
      b = yield
      puts "Hey #{a} #{b}"
  end

  some_method do
    break
  end

  const breakSomeMethod = {}; // Could alternatively use an exception

  function someMethod(one, two) {
    var f, a;
    if (typeof one == 'function') {
      f = one;
      a = 42;
    } else {
      a = one;
      f = two;
    }

    var b = f();
    if (b === breakSomeMethod) {
      return;
    }

    console.log(`Hey ${a} ${b}`)
  }

  someMethod(() => breakSomeMethod);

You have to ask yourself, why are those middlemen there at the moment? We have digital trading platforms / banking systems, the technological side of it is not the issue.

It's because regulation says only certain institutions are allowed to perform certain transactions, and have to perform certain checks, etc. I'm not saying there aren't inefficiencies that aren't directly related to regulation, eg. monopolistic behaviours. But that's the side-effect/price you pay for some kind of oversight. There is of course lots of room for improvement in the systems/regulation we have.

When you look at the history of where the regulations came from, it's usually in response to a major crisis. Humans tend to be reactionary, especially the ones in positions of power when they're enacting laws that limit their paymasters.

The behaviour of said percentage-takers over the last century haven't exactly made regulation the saviour of the common citizenry either.

Look at the most recent major economic crisis of 2008. The main reason it was so devastating was due to rolling back regulation from previous crises, along with "innovative" financial products that regulators had turned a blind eye to. What do you think would have happened to business lending (ie. jobs) and the stock market (ie. people's pensions) if there had been zero regulation and no ability to inject liquidity into the system?

Decentralised systems are always more inefficient. If certain kinds of transactions are currently cheaper, it's due to lack of regulation (lack of competition in many cases is sadly a symptom of regulation). When the inevitable economic crises present themselves (assuming it ever gets used for anything serious), regulators won't stand by and do nothing.

Coins going up in value just because they are scarce or first movers, is just like Pets.com being valuable because they have a good domain name.

Isn't scarcity baked in to Bitcoin? Any investments made using it will have to return more than the deflation / speculative-hoarding rate, which means useful things won't get funded.

https://www.thenation.com/article/world/why-the-us-really-bo...

“the vast destruction wreaked by the bombings of Hiroshima and Nagasaki and the loss of 135,000 people made little impact on the Japanese military.”

- Plaque hanging in the National Museum of the US Navy

In its one paragraph, it makes clear that Truman’s political advisers overruled the military in determining how the end of the war with Japan would be approached.

"the use of this barbarous weapon at Hiroshima and Nagasaki was of no material assistance in our war against Japan"

- Truman's chief of staff

“the Japanese position was hopeless even before the first atomic bomb fell, because the Japanese had lost control of their own air.”

- Commanding general of the US Army Air Forces

“[Byrnes] was concerned about Russia’s postwar behavior…[and thought] that Russia might be more manageable if impressed by American military might, and that a demonstration of the bomb might impress Russia.”

- Manhattan Project scientist Leo Szilard, talking about Secretary of State James Byrnes

It doesn't seem like dropping the bombs served any military purpose.

Aside from the environmental issue, I think Bitcoin is a poorly designed currency that ignores economic history/principles.

I have a really low expectation of it being able to provide price stability.

All of the cryptocurrencies I've seen so far seem to based on a simplistic and fundamentally flawed view of economics. A long term trend (whether inflationary or deflationary) in the overall supply is insufficient to target price stability.

A currency's supply needs to increase/decrease in response to what's circulating at this moment in time. If the overall supply is increasing but everybody is squirrelling it away or deleveraging debt positions, then you're still going to have deflationary effects. Case in point, roughly 20% of USD was minted in the last year or so, with pretty much no inflation. Similarly with something like Bitcoin, if some event were to trigger a spending/selling spree (or a debt bubble were to form) then you would have inflationary effects.

What's needed is coordination to increase/decrease the supply as needed. That could be done with some kind of decentralised voting system. But I'm not sure it could react fast enough in a crisis, or be able to direct the action to the right parts of an economy to avoid the kind of damage that takes decades to undo.

I'm not sure he's a bullshitter exactly. He's wildly overoptimistic and is immune to reality to a large degree. The thing is, those can be really good traits for advancing the state of the art and developing new things.

If he wasn't like that, he might not have done some of the worthwhile things he's done. I definitely wouldn't take anything he says at face value, but I think there's value in him being like that.

I'm one of the engineers that worked on this. It was the first Rust production app code I've written so it was a really fun project.

While there are obvious flaws with the analogy (like any analogy), I think the comparison with eyesight (or touch, etc.) is about making people think of the mind as more of a sensory organ. One that gives you input that may or may not be useful to you, rather than as something that defines you.

I don't really see that as a dissociative practice, but more as the prerequisite for being able to start on the long term journey of challenging and changing your thought patterns.

I can fathom why governments call deflation the big enemy.

The answer lies in who the governments are that are saying that. They're the advanced economies which are well developed and have good regulatory systems, the ones that have little to no risk of hyperinflation. And, for them, deflation is worse than some (non-hyper) inflation. It's also much harder to get out of, Japan is still sort of stuck 20-30yrs later despite taking more and more extreme measures.

To circle back to the parent comment topic, ie. people think printing money always causes inflation: You mention Japan. They have printed so much that their central bank owns about 45% of the national debt. And they still have no inflation.

we keep having mysterious debt-fueled collapses.

I don't think they're that mysterious. Most seem to be caused by human irrationality / group-think (bubbles), in combination with complex financial instruments that magnify the effects of a burst (ie. unwinding of massive leverage).

The actual killer feature being their ability to reduce attack surface substantially by simply having fewer syscalls that can be abused

Can you not use Seccomp for that?

Why are you quoting figures for the entire tax take in a discussion about healthcare? To give you some perspective, the healthcare-only figures for those countries are US: 16.8%, Denmark: 10.3%, Sweden: 11%, Germany: 11.2%, France: 11.1% and UK: 9.9%. Data here:

https://data.worldbank.org/indicator/SH.XPD.CHEX.GD.ZS?year_...

There were only a couple of people discussing that, and only a handful of comments. Most of the discussion seemed to be about how terrible the terms were and whether there were any alternatives to YouTube.

My limited understanding is that heat is related to the square of the voltage. And that by reducing the size of a transistor, you can lower the voltage. I don't think you can lower the voltage by quite as much as the reduction in size, so there must be a point when you can't just pack more in. Though gate design or choice of materials can reduce the voltage needed as well. They can also make the chip smarter about switching off parts that aren't needed at a given point in time to keep overall heat down.

It's much simpler than that. It actually makes writing a compiler easier as you have higher level abstractions to work compared to generating machine code. There are many languages that compile to C which should prove to you that it can be done. I don't see why targeting C++ would be any different and I'm sure there are languages already out there that do.

I personally find larger version numbers a bit odd. Generally people tend to work better with smaller numbers. I think the Ubuntu system is pretty good, use the major version for the year and have the month as the minor version. The Chrome 2 month releases could go 1.1, 1.3, 1.5, etc. That way they wouldn't chew through so many numbers. Ultimately I guess projects must go through a reset of their versions before they get to really ridiculous numbers.