jagrsw
If a model were actually capable of scheming, it would also have enough situational awareness from its training corpus to know that <thought> parts are monitored too.
If the monitor catches the model writing "let's deceive the user", it's definitely scheming. But if the monitor finds nothing, you've learned almost nothing.
<absence of evidence != evidence of absence>
bank (loans), immigration and investors can be interested, but their interests are not covering every corporation out there.
Cow A: "That building smells like blood and steel. I don't think we come back out of there"
Cow B: "Maybe. But the corn is right there and I’m hungry. To stop me, you'd have to compel me"
Past safety is not a perfect predictor of future safety.When a project makes 'big claims' about safety, less technical users might interpret that as 'production ready'. My caution is caused by the fact that modifying the runtime is high-risk territory where regressions can introduce vulns that are distinct from the memory safety issues you are solving.
The goal is to prevent the regression in the first place. I'm looking forward to seeing how the verification matures and rooting for it.
At the same time, however, the author seems to be operating on the principle: "If I don't make big claims, no one will notice." The statements about the actual security benefits should be independently verified -this hasn't happened yet, but it probably will, as the project is gaining increasing attention.
I'm a little concerned that no one (besides the author?) has checked the implementation to see if reducing the attack surface in one area (memory security) might cause problems in other layers.
For example, Filip mentioned that some setuid programs can be compiled with it, but it also makes changes to ld.so. I pointed this out to the author on Twitter, as it could be problematic. Setuid applications need to be written super-defensively because they can be affected by envars, file descriptors (e.g. there could be funny logical bugs if fd=1/2 is closed for a set-uid app, and then it opens something, and starts using printf(), think about it:), rlimits, and signals. The custom modifications to ld.so likely don't account for this yet?
In other words, these are still teething problems with Fil-C, which will be reviewed and fixed over time. I just want to point out that using it for real-world "infrastructures" might be somewhat risky at this point. We need unix nerds to experiment with.
OTOH, it's probably a good idea to test your codebase with it (provided it compiles, of course) - this phase could uncover some interesting problems (assuming there aren't too many false positives).
What a shift in the last 5 years (never -> 100 years -> 11)
By this logic, a vast parallel search running on Commodore 64s that produces an answer after BeaverNumber(100) years would be almost AGI, which doesn't pass the sniff test.
A more meaningful metric would be more multiplicative in nature.
That's wrong. It knows how to process and signal low carbohydrate levels in the blood, and it knows how to react to a perceived threat (the Moro reflex).
It knows how to follow solid objects with its eyes (when its visual system adapts) - it knows that certain visual stimuli correspond to physical systems.
Could it be that your concept of "know" is defined as common sense "produces output in English/German/etc"?
We are born with inherited "data" - innate behaviors, basic pattern recognition, etc. Some even claim that we're born with basic physics toolkit (things are generally solid, they move). We then build on that by being imitators, amassing new skills and methods simply by observation and performing search.
When one turned away, the message would instantly become different, like changing "Down with the heat" to "Down with the cops" - https://sztukapubliczna.pl/pl/precz-z-u-palami-pomaranczowa-...
https://en.wikipedia.org/wiki/Orange_Alternative
the whole world is a work of art, so even a single policeman standing in the street is a work of art
Misses clear definitions (what counts as "friendship with self"?) and the mechanism (how X->Y). Anecdotes/quotes != proofs.
IOW, prestige != proof. Two quick checks 1) strip the names - does the reasoning still stand? 2) Flip to counterexamples - does the thesis survive? We all know people who are hard on themselves but deeply loving to others.
Nice essay but treat it as a opinion to test, not a truth to inherit. The thread reads as if the case were already proven.
I don't know... I understand the history and reasons for this capitalization behavior in Turkish, and my native language isn't English, which had to use a lot of strange encodings before the introduction of UTF-8.
But messing around with the capitalization of ASCII <= codepoint(127) is a risky business, in my opinion. These codepoints are explicitly named:
"LATIN CAPITAL LETTER I" "LATIN SMALL LETTER I"
and requiring them to not match exactly during capitalization/diminuitization sounds very risky.
Longer: A Class I inverter/appliance relies on PE. A single insulation fault (live -> chassis) will put the chassis at line potential if PE isn’t connected.
If you run other Class-I loads (eg. fridges) downstream of a GFCI but don’t carry PE, a hot-to-chassis fault on the load won’t reliably trip anything until there’s a return path (often a person).
Buy a customer-oriented device instead, if you can. I vaguely remember there are plenty of them on the market with built-in batteries. They should have RCD/GFCI and overcurrent protection (and thermal, and BMS included) per outlet (or per bus).
If you want to stick with your current inverter, here are some thoughts from first principles:
- ground it while using, but this might be hard at a remote camping site (maybe use a grounding rod?). If it's a similar model to the one in the article, it must be grounded.
- a GFCI/RCD rated for 30mA or less with 15-20A circuit breaker (I'd suggest type-A if in EU) that matches your wiring and outlets.
There should be ready-to-go boxes that provide RCD+OC, and maybe you're already using one.
I think this could be considered intentional, because in most countries, connecting this inverter to anything (source, sink) would require certification (+tests), as it doesn't have standard electrical outlets (it varies from country to country, but in the countries I've seen, either certification is required or connecting wall/ceiling lamps is exempted from this, but verification must be done afterward).
Agreed, a long run adds so much impedance that during a short circuit, the breaker won't trip instantly. It will just sit there and let the fault current cook the wires.
Various jurisdictions require a fault loop impedance test for installations (and discussed one looks "fixed"). This cannot be eyeballed from a wire diameter table, must be measured.
A 3kW inverter powering a fridge through extension cords (fridges/compressors can have serious inrush current). You can't just snake "yolo" cables through a house for anything drawing serious amps (say, more than 5).
I'm willing to bet zero impedance or insulation/continuity tests were done. I hope the inverter has the RCD protection included.
This "works" 99.9% of the time. Now multiply 0.1% by every person who sees this and thinks it's a clever hack.
Update: He's plugging an extension cord directly into the inverter's output terminals? A 3kW inverter at 120V can push 25A continuously (and likely no RCD in the path). That can melt a 10/15A cord. The inverter's own breaker (say, 30/40A) is there to protect the inverter, not the cord. The cord may "become" the fuse long before the breaker trips on an overload (it doesn't trip at 30A instantly, more like at 100-200A if it's equivalent to EU class B/C).
Update2: I'm against overregulation and panicing at every perceived threat, but I must say, I wouldn't mind an inspection taking a look for the sake of neighbors.
Update3: The PDF (https://cdn.shopify.com/s/files/1/0746/0415/1079/files/POW-L...) says that the AC input "maximum bypass overload current" is 40A. If he plugs the inverter into a wall outlet for charging/bypass, it will let his appliances pull 40A through a standard 15A socket. The main apartment panel will eventually trip, hopefully.
I personally use weechat inside nsjail on a raspberry pi (isolated rpi is enough here, but just for fun): https://github.com/google/nsjail/tree/master/configs
I guess I'm generally in favor of an open-border policy (or at least immigration based on promises of work, verifiable by a work contract).
Benefits are usually tax-based, and immigrants pay taxes (or, it's always possible to set it up that taxes are paid).
> but no person that is alive today had anything to do with it
They do. They're using land and resources taken from their former hosts which is a deep moral grey zone. Leaving home would be an option. If it's deemed too invasive, perhaps not penalizing people who want to do the same (minus stealing the land forcibly) would be a good first step.
How do you argue that the behavior of your predecessors is acceptable (and your presumed right to reside in what's currently known as United States) while those who now attempt to enter the territory suddenly become dangerous criminals?
Would your argument be more understandable to the reader than “might is right” or “if it is against me, it is unfair and abuse, if I do it to others, it is a sacred law”?
Printing arbitrary output to most terminal emulators is some security risk (even if pretty much everyone does it). Many suffer from vulnerabilities, both past and present, that can allow specially crafted text to inject commands back into the shell. The issue lies in the complex and often legacy standards for handling control characters and escape sequences.
Even xterm is not entirely immune to these problems and has had security advisories issued in the past.
While this attack surface has received attention from sec-researchers in the past, it's not remotely comparable to the scrutiny applied to web browsers. The ecosystem around terminals generally lacks the massive, continuously-funded bug bounty programs and large-scale, constant fuzzing that browsers are subjected to.
Any predictable pattern, including when you disengage, is just another feature for the pricing model. If the model learns you reliably leave after 3 hours, it will simply front-load the surge pricing into that initial window.
Analysis: This user loses disengages during 75% of the
time and belongs to a group of 5% who do the same. The
expected revenue for this group over a longer period
and with multiple users is 24% lower than for the
average user.
Action: Since 80% of theirs engagements last for at
least 12 hours, ads should be shown and prices
increased only within the first three hours.
Hope this helps :)Yup. The price jump isn't just a "surge." It's the algorithm calculating the highest price you'll tolerate without abandoning the app long-term, no matter availability of cars (which can be related, but from CFOs perspective that's not the metric to optimize)
This personalized price discrimination is precisely the kind of manipulation geohot is describing.
It's the same principle as (an old story) booking.com charging Mac/Safari/iphone users more.