Hacker Newsnew | past | comments | ask | show | jobs | submit | steamrolled's commentslogin

Assembly, assign, assert, assume, associate... I think most of what you're picking up is not actually naughty.


Good ol' Scunthorpe problem.


Yea, if you remove the star at the end, it goes back to normal


> Because they are vibrating, a lot of that energy is being wasted in brownian motion. So the denser it is, the more your average vector is going to be toward more dense brownian motion as the particles interact and induce more brownian motion ... Seems pretty intuitive to me.

So this is why warm objects weigh more?


Warm objects actually do weigh more than their counterfactual cold versions haha. The stress energy tensor is the quantity to look at here.


Relevant paper: https://iopscience.iop.org/article/10.1088/0143-0807/8/2/006...

Abstract: "According to the weak form of the equivalence principle all objects fall at the same rate in a gravitational field. However, recent calculations in finite-temperature quantum field theory have revealed that at T>0 heavier and/or colder objects actually fall faster than their lighter and/or warmer counterparts. This unexpected result is demonstrated using elementary quantum mechanical arguments."

Downloadable here: https://www.academia.edu/download/109363694/download.pdf



I feel like you have somehow found the least authoritative source for the wonderful new information provided...

why did you choose that one? serious question, because I'm trying to understand your process (and yes, maybe gently challenging it, but unsure if I should, bc you are clearly knowledgeable in specific ways about this)


Thanks, I appreciate it


This reads like a sarcastic quip so, sorry if it wasn't but, they do. Solve for m in E=mc^2 and see what happens when objects have more energy.


I don't get why EE education emphasizes problems of this sort. The infinite grid is an extreme example, but solving weirdly complicated problems involving Kirchoff's laws and Thevenin's theorem was a common way to torture students back in my day...

Here, I don't think it's even useful to look at this problem in electronic terms. It's a pure math puzzle centered around an "infinite grid of linear A=B/C equations". Not the puzzle I ever felt the need to know the answer to, but I certainly don't judge others for geeking out about it.


I was about to say "they still torture students this way" but stopped myself when I remembered I took Circuits 1 and 2 back in 2007. So maybe my knowledge is dated too...

It's a weird butterfly effect moment in my career though. I had an awesome professor for circuits 1, and ended up switching majors to EE after that. Then got two more degrees on top of the bachelor's


> I don't get why EE education emphasizes problems of this sort

Last I checked, they don't. I certainly never hit an "infinite grid of resistors" in general circuits and systems except as some weird "bonus" problem in the textbook.

Occasionally, I would hit something like this when we would be talking about "transmission lines" to make life easier, not harder. ("Why can we approximate an infinite grid of inductors and capacitors to look like a resistor?")

It's possible that infinite grid/infinite cube might have some pedagogical context when talking about fields and antennas, but I don't remember any.


If all you mind is the EE curriculum then ok. Or else there is an interesting work of Gerald Westendorp on the web [1] on how allowing other classical passive components (Ls & Cs) you can get discretizations (and hence alternative views) of a very wide class of iconic Physics partial differential equations (to the point that the question is more what cannot be fit to this technique). G. W. is alive and kicking in mathstodon.

[1] https://westy31.nl/Electric.html


There are two parts to education. One is to impart knowledge, the other is to filter the students.


The third is to challenge students. With unusual concepts, preferably.

How else to create students capable of solving problems we cannot anticipate today?

Not to mention, that understanding strange problems is a very efficient way to broaden horizons.


You're missing general problem solving. If all people do is encounter problems they've already seen before, well, we have lookup tables for that kind of thing.


Not entirely wrong but it's a little too easy to use that argument for squashing any criticism for education content.


> Here, I don't think it's even useful to look at this problem in electronic terms

I always thought this problem was a funny choice for the comic, because it’s not that esoteric! It’s equivalent to asking about a 2d simple random walk on a lattice, which is fairly common. And in general the electrical network <-> random walk correspondence is a useful perspective too


> solving weirdly complicated problems involving Kirchoff's laws and Thevenin's theorem was a common way to torture students back in my day...

Hey now, those actually come up sometimes.


One of my core grips with STEM education, mainly the math heavy part of it, which frankly is most of it, is that it is taught primarily by people who love math.

The people who loved application and practical solutions went to industry, the people who got off spending a weekend grinding a theoretical infinite resistor grid solution went into academia.


Loving math is not necessarily a problem. But if you want others to love it too, you have to explain it in a way that makes them see the light.

A lot of STEM education is more along the lines of "take the rapid-fire calculus class, memorize a bunch of formulas, and then use them to find the transfer function of this weird circuit". It's not entirely useless, but it doesn't make you love the theory.


In school I would have relished solving this problem. Now I wonder if it has any application.


To make you think, and not become another monkey moving blocks along


> Gary Marcus isn't about "getting real", it's making a name for himself as a contrarian to the popular AI narrative.

That's an odd standard. Not wanting to be wrong is a universal human instinct. By that logic, every person who ever took any position on LLMs is automatically untrustworthy. After all, they made a name for themselves by being pro- or con-. Or maybe a centrist - that's a position too.

Either he makes good points or he doesn't. Unless he has a track record of distorting facts, his ideological leanings should be irrelevant.


He makes many very good points:

For example he continusly calls out AGI hype for what it is, and also showcases dangers of naive use of LLMs (eg. lawyers copy-pasting hallucinated cases into their documents, etc). For this, he has plenty of material!

He also makes some very bad points and worse inferences: that LLMs as a technology are useless because they can't lead to AGI, that hallucation makes LLMs useless (but then he contradicts himself in another article conceding they "may have some use"), that because they can't follow an algorithm they're useless, etc, that scaling laws are over therefore LLMs won't advance (he's been making that for a couple of years), that AI bubble will collapse in a few months (also a few years of that), etc.

Read any of his article (I've read too many, sadly) and you'll never come to the conclusion that LLMs might be a useful technology, or be "a good thing" even in some limited way. This just doesn't fit with reality I can observe with my own eyes.

To me, this shows he's incredibly biased. That's okay if he wants to be a pundit - I couldn't blame Gruber for being biased about Apple! But Marcus presents himself as the authority on AI, a scientist, showing a real and unbiased view on the field. In fact, he's as full of hype as Sam Altman is, just in another direction.

Imagine he was talking about aviation, not AI. 787 dreamliner crashes? "I've been saying for 10 years that airplanes are unsafe, they can fall from the sky!" Boeing the company does stupid shit? "Blown door shows why airplane makers can't be trusted" Airline goes bankrupt? "Air travel winter is here"

I've spoken to too many intelligent people who read Marcus, take him at his words and have incredibly warped views on the actual potential and dangers of AI (and send me links to his latest piece with "so this sounds pretty damning, what's your take?"). He does real damage.

Compare him with Simon Willison, who also writes about AI a lot, and is vocal about its shortcomings and dangers. Reading Simon, I never get the feeling I'm being sold on a story (either positive or negative), but that I learned something.

Perhaps a Marcus is inevitable as a symptom of the Internet's immune system to the huge amount of AI hype and bullshit being thrown around. Perhaps Gary is just fed up with everything and comes out guns blazing, science be damned. I don't know.

But in my mind, he's as much BSer as the AGI singularity hypers.


> Compare him with Simon Willison, who also writes about AI a lot, and is vocal about its shortcomings and dangers. Reading Simon, I never get the feeling I'm being sold on a story (either positive or negative), but that I learned something.

Very true!


Marcus' points routinely fail to pass scrutiny, nobody in the field takes him seriously. If you seek real scientifically interesting LLM criticism, read François Chollet and his Arc AGI series of evals.


The complaints about licensing seem a bit weird given that the company actually accommodates hobbyists. They have a $100-something perpetual home license that doesn't require internet access.

Most other vendors of niche "pro" software just give the middle finger to hobbyists and want you to pony up thousands of dollars for an annual subscription.

I think it's perfectly OK to say "I don't need this, open-source tools work for me". Just like you can use KiCad instead of Cadence for PCB design. But getting angry at Mathworks for wanting money from commercial users seems weird.


I'm frustrated that they push their product on undergrad engineering classes so heavily. Except for a few poorly taught weeks of C++, most of my classmates never leaned anything else. Admittedly, Matlab is a very good product for modeling and learning about controls, but they use this advantage to make sure all the fresh undergrads only know how to program in their product.


> Formal Methods in general are underrated in the industry. Pretty much no large companies except AWS (thank you Byron Cook!) use them at a large scale.

At least Microsoft and Google poured a lot of money into this by funding well-staffed multi-year research projects. There's plenty of public trail in terms of research papers. It's just that not a whole lot came out of it otherwise.

The problem isn't that the methods are underrated, it's that they aren't compatible with the approach to software engineering in these places (huge monolithic codebases, a variety of evolving languages and frameworks, no rigid constraints on design principles).


Can you ELI5 what formal methods are and how not the industry standard apparently? As a complete noob, from what I'm reading online, they're pretty much how you should approach software engineering, or really any sort of programming right?


Formal methods = “this software cannot do things it shouldn’t do”, I have formally proven it ALWAYS EXECUTES THE WAY I CONSTRAINED IT TO.

Contrast with

Testing = “My tests prove these inputs definitely produce these test outputs”

IME Formal methods struggle making contact with reality because you really only get their promise “it always does what it is constrained to do” when every abstraction underneath provides the same guarantee, I wager most CPUs/GPUs aren’t verified down to the gate level these days.

It’s just faster to “trust” tests with most of the benefit, and developing software faster is very important to capturing a market and accruing revenue if you are building your software for business reasons.

EDIT: My gate-level verification remark is a bit extreme, but it applies to higher layers of the stack. The linux kernel isn’t verified. Drivers are sometimes verified, but not often. There is an HN comment somewhere about building a filesystem in Coq, and while the operations at the filesystem layer are provably correct, the kernel interfaces still fail. The firmware still isn’t proven. The CPU itself running on has undisclosed optimizations in its caches and load/store mechanisms which just aren’t proven, but enabled it to beat the competition on benchmarks, driving sales.


The example about the filesystem really drove the idea home. Thanks a lot!


The original post asserted the article is nonsense; you're trying to justify that by saying you don't like the author's writing style. Two separate things...

The article is mostly correct, although it makes some weird claims (e.g., the Shellshock bug had nothing to do with the class of bugs the article is complaining about - it was a vulnerability in the shell itself). It definitely has a "newcomer hates things without understanding why they are the way they are" vibe, but you actually need that every now and then. The old-timers tend to say "it was originally done this way for a reason and if you're experienced enough, you know how to deal with it", but what made sense 30-40 years ago might not make much sense today.


I dunno, "mostly" normally means some large fraction, maybe 50% or 90% depending on the person.. Given that executing commands by itself is neither a bug nor a security vulnerability (those only occur from bad/lack-of quoting), the majority of the article is wrong.


The main reason system() exists is that people want to execute shell commands; some confused novice developers might mix it up with execl(), but this is not a major source of vulnerabilities. The major source of vulnerabilities is "oh yeah, I actually meant to execute shell".

So if you just take away the libcall, people will make their own version by just doing execl() of /bin/sh. If you want this to change, I think you have to ask why do people want to do this in the first place.

And the answer here is basically that because of the unix design philosophy, the shell is immensely useful. There are all these cool, small utilities and tricks you can use in lieu of writing a lot of extra code. On Windows, command-line conventions, filesystem quirks, and escaping gotchas are actually more numerous. It's just that there's almost nothing to call, so you get fewer bugs.

The most practical way to make this class of bugs go away is to make the unix shell less useful.


most calls to system() that I've seen could be replaced with exec without much difficulty. There's relatively few that actually need the shell functionality.


system() involves fork()ing, setting up signal handlers, exec()ing and wait()ing. You won't be replacing it with exec, most of the time you'll be reimplementing it for absolutely no reason.


Python has os.spawnl, os.spawnv, etc., which fork()s, wait4()s, etc., without involving a shell. This is much better; this is the library function you should be using instead of system() most of the time. Unfortunately I don't think glibc has an equivalent!

    strace -o tmp.spawnlp -ff python3 -c 'import os; os.spawnlp(os.P_WAIT, "true", "true")' 
In parent:

    clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fdc03233310) = 225954
    wait4(225954, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 225954
    --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=225954, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
In child:

    set_robust_list(0x7fdc03233320, 24)     = 0
    gettid()                                = 225954
    clock_gettime(CLOCK_MONOTONIC, {tv_sec=2458614, tv_nsec=322829153}) = 0
    clock_gettime(CLOCK_MONOTONIC, {tv_sec=2458614, tv_nsec=323030718}) = 0
    execve("/usr/local/bin/true", ["true"], 0x7ffdc5008458 /* 44 vars */) = -1 ENOENT (No such file or directory)
    execve("/usr/bin/true", ["true"], 0x7ffdc5008458 /* 44 vars */) = 0
Here, I think strace shows clone() rather than fork() because glibc's fork() is a library function that invokes clone(), rather than a real system call.


> Python has os.spawnl, os.spawnv, etc., which fork()s, wait4()s, etc., without involving a shell.

Good. How do you pipeline commands with these?


These functions can't do it. In Python you have to use the subprocess module if you want to pipeline commands without the bugs introduced by the shell. From https://docs.python.org/3.7/library/subprocess.html#replacin...:

    p1 = Popen(["dmesg"], stdout=PIPE)
    p2 = Popen(["grep", "hda"], stdin=p1.stdout, stdout=PIPE)
    p1.stdout.close()  # Allow p1 to receive a SIGPIPE if p2 exits.
    output = p2.communicate()[0]
Of course, now, nobody has an hda, and dmesg is root-only. A more modern example is in http://canonical.org/~kragen/sw/dev3/whereroot.py:

    p1 = subprocess.Popen(["df"], stdout=subprocess.PIPE)
    p2 = subprocess.Popen(["grep", "/$"], stdin=p1.stdout, stdout=subprocess.PIPE)
    p1.stdout.close()
    return p2.communicate()[0]
Note that the result here is a byte string, so if you want to print it out safely without the shell-like bugginess induced by Python's default character handling (what happens if the device name isn't valid UTF-8?), you have to do backflips with sys.stdout.buffer or UTF-8B.

Python got a lot of things wrong, and it gets worse all the time, but for now spawning subprocesses is one of the things it got right. Although, unlike IIRC Tcl, it doesn't raise an exception by default if one of the commands fails.

Apart from the semantics of the operations, you could of course desire a better notation for them. In Python you could maybe achieve something like

    (cmd(["df"]) | ["grep", "/$"]).output()
but that is secondary to being able to safely handle arguments containing spaces and pipes and whatnot.


Dunno, so much work to achieve so little. I'm even more inclined to stick with shell scripts now


The Bourne shell is definitely less work unless you want your code to correctly or reliably handle user input. Then it's more work.


Not in my experience. Any concrete examples off the top of your head, where it's more work than setting up pipes in python manually?


Fill in the blank to run a docker container which opens the file with user-provided path in (say) vim.

docker run --rm -it ...?

Now run a container doing the exact same thing ("docker-in-docker").

docker run --rm -it -v $DOCKER_HOST:/var/run/docker.sock ...?


> Fill in the blank to run a docker container which opens the file with user-provided path in (say) vim.

Never used docker before, but this seems to work:

    docker run --rm -it debian bash -c 'vim -- "$1"' _ "$user_provided_path"


Looks relatively safe to me, though it doesn't seem to work because debian:latest doesn't have vim in it (so I'm skeptical of your implicit claim of having tried it), and, if $user_provided_path is empty, it defaults to browsing the filesystem. But there are a lot of characters there that are specifically there to avoid footguns; without them, it would seem to work, but it would fail when $user_provided_path contained special characters.

The version I tested was

    docker run --rm -it debian bash -c 'apt update; apt install -y vim; vim -- "$1"' _ "$user_provided_path"


> your implicit claim of having tried it

I tried printing positional parameters, they looked fine. (And already uninstalled docker. What's the point of containerization if you need superuser privileges to use it?)

> if $user_provided_path is empty, it defaults to browsing the filesystem

That's what

    vim -- ""
does.

> But there are a lot of characters there that are specifically there to avoid footguns

What are those characters? --? That's not a lot


Also bash -c '' and "".


The Python code Kragen gave is more characters to type, but fewer footguns.

Shell scripts are much higher in footguns per character than most programming languages.

It is possible for a coder to understand bash so well that he never shoots his own foot off, but it requires more learning hours than the same feat in another language requires, and unless I've also put in the (many) learning hours, I have no way of knowing whether a shell script written by someone I don't know contains security vulnerabilities or fragility when dealing with unusual inputs that will surface in unpredictable circumstances.

The traditional Unix shell might be the most overrated tool on HN.


> The Python code Kragen gave is more characters to type, but fewer footguns.

What are the footguns in this?

    df | grep /$


There are none AFAIK.

Allow me to correct my previous comment: using Python's os.spawnlp or Popen to invoke Unix commands has fewer footguns than using the shell. (Kragen's code only addresses your question of how to set up a pipeline in Python.)


There is posix_spawn(). Some operating systems even implement that as a system call (not Linux). Implementing that as a system call has the advantage that spawning a new process from a process that has huge memory mapping is fast, because the memory mappings don't need to be copied (yes, I know the memory is copy on write, but the mappings themselves have to be correctly copied with the information needed for copy on write).


There's a ton of hobbies like that. There are people who collect out-of-print comic books, sports memorabilia, old militaria, etc. What's the point of any of it? It's the joy of having a hobby and being a part of a community, not the utility of the gear itself.


"Extremist" is just a pejorative variant of "radical". I assume they're using it tongue-in-cheek.

When it comes to speech, it's really not hard to imagine positions that would have been controversial at any point in the history of the US. That doesn't mean you can't hold them, but others don't need to agree, and that's how you end up with labels of this sort.


Aside from the bit about "frontiers", Article 19 of the UN Universal Declaration of Human Rights is pretty straightforward:

> Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers.

As is the First Amendment to the US Constitution:

> Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances.

I can't speak for Pete. However, given that the expressed position of influential portions of the US government (as well as many of my peers and acquaintances) runs counter to the letter and the spirit of Article 19 and the spirit (if not the letter) of the First Amendment, I consider myself to be a free speech extremist.


Because there are inumerable forms of banned speech. Because freedom of speech is in reality a very narrow construct. See Hustler Magazine v. Falwell 1998.... or just watch the last few scenes of the movie.

https://youtu.be/gh30mLyNQM0


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: