Hacker News new | past | comments | ask | show | jobs | submit | kbenson's comments login

Funnily enough, I have indeed have had part of a tooth (an impacted wisdom tooth) come off when eationg something, and was kind of grossed out that my food could contain this small white hard stone-like thing... until later that day I realized I was missing a part of a tooth.

Actually, it's happened twice, as about 15 years after that I had a bad cavity and fracture in a forward molar, and a few days before a scheduled root canal it happened again, but this time I suspected what had happened as soon as I encountered something hard all of a sudden while chewing something that shouldn't really have bits as hard as that in it.

Which is to say, their response that perhaps it was your own tooth may not have been as out of left field as you might have thought. It's probably a somewhat common occurrence.


You don't even have to make the argument that Apple is untrustworthy. The stronger argument is that you can't know what Apple will be like in the future, or even if they will still be independent (which seems far fetched since they're so big) or a division that deals with user data won't get sold off with the data even if it's to a respectable company, because that company may eventually sell if to a slightly less respectable company, and repeat.

The risk for PII being utilized nefariously never goes away as long as it exists, so the only same stance is to not allow it to exist in others handle if at all possible. It's the same reason you don't share your banking credentials with your friends. Sure, you might trust them, but you can't know the future, so why even expose yourself to risk you don't have to?


> Apple used to have privacy as the differentiating and profit-driving factor.

> This will immediately get thrown out of the window when it hurts profit

This is the important thing I'm always trying to note to people that think incentives are enough (as I used to). You can never know what the incentives of the company will be 5, 10, 15 years from now, or whether that company or division will exist or have been sold to some other company.

Incentives based on current conditions only matter for outcomes that don't have ramaifications far into the future. That's definitely not data collection and privacy, where you could find that 10 years worth of collected information about you has been sold at some future date.

And lest anyone think they can predict the stance a company will have on a topic a decade or two later, all I can say is that any example someone can point to of a company that has stayed the course we can easily look at point in history where a series of events could have gone the other way and they would be close to being bought out if not defunct. Even Apple had a period where they were bailed out by investment from Microsoft, and many other large names of that period were gobbled up.

Always keep in mind, Sun was an amazing company with amazing products and engineers that embraced open source and competed with Microsoft in the enterprise market, and eventually after declining they got bought by Oracle.


If it's posted through a publishing platform (not just a commend on one or on a public site), it's very possible they do an automatic conversion of some of the common cases. That could also be filtering down to comment boxes and stuff, I'm not sure.

That's not to say that generated content doesn't use them, just that using them as an indicator might require a bit of nuance based on where you're seeing them.


Automatic conversions have been happening for a long time. In fact, a few years ago there was some combination of settings on my terminal locale settings and man (well, troff/groff most likely) was converting hyphens in param definitions to some sort of dash character, meaning I couldn't copy and paste out of the man page. I think it also affected perldoc for the same reason.

I don't doubt there are publishing platforms that do it automatically as well, so I wouldn't count on seeing them as an indicator of generated output, even if it may be processed in some manner.


This is because the original was written using the wrong markup. When the output was ascii, nobody noticed, but it matters when the output is unicode.


That's revisionism. It was considered correct historically, before someone decided to unilaterally declare all existing man pages "wrong".


It's like we spent twenty years writing (mindlessly copying) web pages with &mdash and only viewing them with lynx, and then somebody makes a graphical browser and the mistake is apparent, but I don't think the browser is in the wrong.


Context: https://lists.debian.org/debian-devel/2023/10/msg00085.html

Money quote:

  This issue does indeed have a history of provoking unhinged lunacy.


I've lived in suburbs where I had a good idea of who lived in each house, talked to some of them semi-regularly, and kids ran around the neighborhood together every day, and I've lived in neighborhoods where everyone stays inside and nobody interacts with each other and even the few group things explicity set up (neighborhood street potluck, chili cookoff at the attached park) couldn't be sustained. I moved directly from the former to the latter, so the difference was stark.

I think it has much more to do with demographics and type of people that happen to be living there, and whether there's an existing community. The more lively neighborhood in my case was in a "worse" neighborhood with cheaper houses, while the new neighborhood was all newly build housing. We were all starting from scratch with each other, with some people maybe having a year or so more history than others (as they staged builds 5-10 houses at a time). Community is a frail thing, and needs to be tended or it will wither, and sometimes it dies before it even has a chance to flourish.


His articles are very long, but I find the narratives they present to be compelling. This one is a bit different than the prior two, in that it's summarizing them and putting them into context, while also doing a lot of explaining (maybe too much) about why he is a skeptic and why he thinks it's important, compared to being cautiously optimistic (which he excoriates with justifies his reasoning for doing so).


Neither of those are equivalent to variable binding, which is what most SQL libraries provide, specifically because they don't actually solve the problem since they're still doing string substitution. Putting a double quotes in $1 in your "good" execute example will allow you break out of what's expected and then you're Bobby Tables.

Your python example at the bottom is correct, in that each separate element is more correct in that it allows each arg to be passed as an element, so there's no option to break out through quoting characters. SQL binds are like that in most ljbraries, even if they don't look like it. The parser knows a single item below there so if it passes it along as such. You cannot escape it in the same way.


I don’t really follow. My “good” example and the code at the bottom are the same.

sh is smarter than just doing string interpolation and ”$1” is passed on as a single argument, no matter what:

  > run(["sh", "-c", 'echo "$1"', "--", 'a"'])
  a”
Whereas if it were simple string interpolation, you’d see this:

  > run(["sh", "-c", 'echo "a""')
  --: 1: Syntax error: Unterminated quoted string
It’s the same special casing that gets "$@" right.


That requires you quote the param in the sintr to ensure that params are groups as expected. E.g.

    # cat pvars.sh
    #!/bin/bash
    echo "\$1=$1"
    echo "\$2=$2"
    echo "\$3=$3"
    # sh -c './pvars.sh "$1" $2 $3' -- 'a b' 'c d'
    $1=a b
    $2=c
    $3=d
The whole point of passing in an array and using something like exec (or system(), if provided as it handled the fork and wait for you) is that you avoid the overhead of the shell starting up at all and parsing the command line, and it lets you define each param exactly as needed since each param is its own array item. You don't need to worry about splitting on space or the shell splitting params on space, or quoting to group items. If you want the param to be:

    foo "bar baz" quux
as one singular parameter, you just make that the contents of that array item, since no parsing need be done at all.

If you have an array of params and you're jumping through hoops to make sure they're interpreted correctly by the shell you call execute a process, you're likely (depending on language and capabilities) wasting both cycles and over complicating the code when you can just call the program you actually want to execute directly and supply the params. Alternatively, if you have all the params as one long string and you want it to be pased as a shell would, then execute the shell and pass that as a param. e.g.

    # perl -E 'system("./pvars.sh","a b","c d");'
    $1=a b
    $2=c d
    $3=
    # perl -E 'system("./pvars.sh","a b","c","d");'
    $1=a b
    $2=c
    $3=d


Thanks for explaining. I feel like we’re talking past each other but it’s my mistake. I should have said it is only useful (not “particularly useful”) if one has compound statements like a pipe or multiple commands. Invoking sh just to run a single command is superfluous and you are right that reaching directly for execve() is better.


Ah, yes. If you want to take advantage of piping commands together through the shell as a subcommand of your program, then a way to make params behave more consistently regardless of content is useful.


OpenSSH is an implementation, SSH is a technology and/or protocol, it doesn't make a lot of sense to compare them that way. Although from later comments RDP seems to have a history in Citrix prior to it's life as RDP, so there are likely clear reasons why it didn't use the SSH protocol (namely that the underlying technology RDP was built on does predate the SSH protocol).


> Something in my childhood I presume.

LOL, I can empathize quite a bit, as someone that has a nasty burn scar on my hand caused by a glob of melted saltpeter and sugar from an accidental ignition of a concoction I was cooking one fourth of July in my youth.


A lot of good lessons to be learned from KNO3. An early lesson was not to melt it and incorporate fuel on a kitchen stove. Next lesson was how to build a outdoor brick stove. Then we learned a couple pounds would fill up several square blocks with dense smoke and burn a hole through blacktop.

Not sure how we made it through our youth without learning what the inside of a jail cell looked like, but I suppose things were different before 9/11.


> An early lesson was not to melt it and incorporate fuel on a kitchen stove.

That was, indeed, an aspect of the problem I alluded to before. I have made it a few times before, and I was going to use the gas grill outside, but it seemed to be acting up, and I didn't trust it, so I thought it would be "safer" to move inside.

Combine that with me iterating on a few different batches with "improvements", such as lining the bottom of the pan with tinfoil so I could lift it out, and then next making an extra large batch... well multiple lessons were learned that day, including how to deal with insurance companies from some shrewd negotiating from my parents, given most the entire kitchen needed to be replaces and the entire house needed to be scrubbed floor to ceiling.

> Not sure how we made it through our youth without learning what the inside of a jail cell looked like, but I suppose things were different before 9/11.

Ha, probably true, especially since my recipe came from a copy of the anarchist cookbook my older brother happened to have (and I wouldn't be surprised if you happened upon it the same way). It's got a lot of dangerous stuff in it, but honestly, as a tool for sparking curiosity it works pretty well.


I grew up with a (stolen, of course) copy of Steal this Book in the house.


As a grade school kid, I was taken to the police station for making a bomb with a couple friends. Fortunately for us, no charges were pressed (presumably because we didn’t manage to ignite the bomb and it was the 70s).


I met someone on holiday whose brother has been blinded for life by a pipe bomb he and a friend made. So the risks of messing around with that sort of thing are very real. Better to couple youthful enthusiasm with some adult oversight. It can still be a lot of fun (see my comments on youth rocketry competitions elsewhere in this discussion).


Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: