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

I think the rub is actually here:

"The participants received either ultra-processed or minimally processed foods for two weeks before swapping diet for the next fortnight. Participants in both diets had access to the same amount of calories and nutrients like sugars, fibre and fat. People were free to eat as much or as little as they wanted. The results were striking. People on the ultra-processed diet ate about 500 more calories per day than those on the unprocessed one"

My understanding is that caloric intake is king.


Weight loss/gain is specifically tied to calories consumed vs calories burned, yes.

But that is not the purpose of the study.

2 groups of people, 2 diets, and the 1 group given an unlimited amount of relatively healthier food, chose to eat less of it and lost weight. The other ate more junk food and gained weight.

That implies that there are non-conscious factors at play and that diets may be more naturally successful if they are comprised of healthier less-processed food even without restriction.

Additionally, this implies that there must be an X factor that takes place in the processing of foods that causes overweight people to keep eating when they have met their caloric requirements.

For context, look at the data regarding nutrient density in vegetables over the last 60 years and see that the nutrients aside from fat/carbs/protein have been on a steady decline year over year.

https://pmc.ncbi.nlm.nih.gov/articles/PMC10969708/

When I put these things into perspective, my hypothesis is this:

Being overweight, commonly viewed as a weakness of character or a sickness of the mind or body, is more likely a symptom of some larger issue.

Evidence of this can be found piecemeal from studies on human diets the world over.

The foods that are readily available to people are making them sick, my guess is that this is from some form of malnutrition. This may be a nutrient malnutrition or some compounding effect that the overprocessing of foods has on the human body that isn't trivial to differentiate from its non-processed counterparts.

I feel it is reasonable to assume that in general overweight and obese people on an ultra-processed diet are overeating in a non-conscious attempt to compensate for a lack of fundamental nutrition in the foods that are available to them.

Therefore, to test the hypothesis, the underlying nutritional issues should first be addressed by eliminating ultra-processed foods from the diet and replacing them with minimally processed foods, the higher in "quality" the better.

Theory: An overweight person will naturally reduce their caloric intake when their diet meets or exceeds their nutritional requirements.

The results, listed in the article above, seem to suggest that this theory is correct.


"processed foods" are just tastier is also consistent with the data, no?


Mazda CX-90


Seems promising. What do you like about them, and is there a particular year you'd recommend?


- No touch screen, but a screen w analog controls

- analog controls, buttons, knobs for all internal functionality like temperature control, sunroof, seat control

- plugin hybrid

- reasonable mileage on only gas

- electric only mode for city driving


Whenever this conversation is had - it seems to completely dismiss the idea of domain. Duplication doesn't happen in a vacuum - it happens within a certain context. Some acceptable conditions for duplication include:

* If two things are semantically different within the context of a domain but require similar functionality.

* Code paths with different risk profiles.

* When new functionality is evolving with domain learnings.


This is the basis of most older async frameworks (see: Tornado, Twisted). A while ago I put together a short talk on how to go from this feature -> a very basic version of Twisted's @inline_callback decorator.

https://github.com/ltavag/async_presentation/tree/master


I recently discovered Menraku, a little more expensive - but truly worth it.


Articles like this make me think about how the software community has chronically under-invested in developing managers. It is not crazy to think that a manager could actually -

* Have the time to know what you are working on

* Set aside time to talk to you about your career development goals

* Help you work and progress towards them - with a plan that is personalized for you.


The reviews aren't for your manager. They are for your manager's manager, and so forth, up the chain to the people who make the compensation and promotion decisions. Reviews give your manager some ammo to deal with those people.


One of the favorite things I've heard of comes from a friend's new job, where he had a upward manager he reports to, but also an engineering manager who works on career/environment/developer-experience topics. Making sure the engineering side of the org is running well, while the more product-driven side does what businesses typically do.

Semi-related, I've somewhat started calling the engineer-advocacy work in the org the "Lorax" position; speaking for the trees, who are not as able to. Where & how this happens varies, & it's not usually a role or position, alike emotional support.


You’re totally right. Companies should invest more in developing managers.

I didn’t talk about this in the article, but (right, wrong, or indifferent) I find it helpful to think about how to help my manager help me.


I think there is some magic lost in how music discovery used to work online over the last 20 years or so. I spent a lot of time on IRC, and then later Waffles.fm working to build my musical library, and discover music. A few things that are sorely missed..

* A community built by common interest in music. Community written articles, recommendations, and friendships built from across the world through music.

* Consumption was not the only form of participation. Ratio maintenance was required - this IMO helped everyone be a "good citizen"

* There was still a formal boundary between "the communities music" and "your music" since you had to download it to listen to it. This helped encourage a more pro-active form of discovery.

* Less emphasis on playlists - more emphasis on artist and album discovery.

* While there was some concept of tiers ( power users, etc ) - there wasn't a tier low enough to subject to pushing advertising through your home speakers.

I tried Qobuz for many years in search of a community that cared about music - and just a couple of months ago finally switched to Apple Music. It was hard to stick with the poor streaming infrastructure (streams cut out all the time) & terrible recommendation engine. A lot of the Apple collection is lossless at this point - and there's no reason not to pick them unless you want to wax philosophical about AAC vs FLAC.


While I agree Systemd timers aren't as ergonomic to set up - there are some benefits that I would basically never give up at this point.

* Running the service on command ( this is the best way to troubleshoot issues with your slightly different environments / cron's version of shell. I've spent many minutes over my career - setting the crontab one minute and the future and waiting for it to run / fail )

* Easily inspecting when the next run of the service is. ( list-timers )

* Straightforward access to the logs ( Always journalctl )

* Specifying environment variables easily

* OnFailure


* Built in locking (so you don't need to worry about two instances of your cron running at the same time)

* Built in functionality for telling when the cron last ran, and whether it was successful or not (so you can do alerting)

* Ability to specify human-readable schedules

* Built-in feature for randomising cron start time to avoid stampeding


The built-in locking is IMO a big deal.

If you have a script that you run every 24 hours, what happens when it takes 25 hours to complete?

(My experience is that this happens only years later, and the people who wrote the cronjob are gone.)


Speaking on OnFailure, one of the unfortunate aspects of systemd timers (which are otherwise quite nice) is you need to do extra work to get proper emails when something fails. Here's how I do this:

Define email-unit-status@.service

    [Unit]
    Description=Email status for %i to root
    After=network.target

    [Service]
    Type=oneshot
    ExecStart=email-unit-status %i

Define email-unit-status (a script)

    #!/usr/bin/env bash
    set -eu
     
    dest="admin@whatever.com"
     
    userflag=
    if [[ $HOME == /home/* ]]; then
      userflag=--user
    fi
     
    html=$(SYSTEMD_COLORS=1 systemctl $userflag status --full "$1" | ansi2html -w -c)
     
    /usr/sbin/sendmail -t <<ERRMAIL
    To: $dest
    From: systemd <${USER}@${HOSTNAME}>
    Subject: SystemD unit failure alert: $1
    Content-Transfer-Encoding: 8bit
    Content-Type: text/html; charset=UTF-8
    Mime-Version: 1.0
     
    $html
    ERRMAIL
Then you can add to a service:

    OnFailure=email-unit-status@%n
You will need to install the ansi2html tool. This stuff should come with systemd really.


Avoiding processed foods is more about avoiding the unknown than avoiding something specific. I would say more analogous to rolling your own tobacco vs buying a pre-packaged cigarette. At least you know what's in there for the most part.


This may be inaccurate now - but a few years ago I stopped at Idahos potato museum. If I remember correctly - the McDonald’s fries are actually a product of a lot of food scientists hard work. There are multiple types of potatoes involved that are turned in to potato product. Those are then mixed together in a specific ratio before they are reconstituted into fry shape. I think even the combination of oils and temperatures are very specific to McDonald’s.


No, they're mostly just cut potatoes. They get a coating with some stuff in it you wouldn't find on homemade fries, and the cooking is of course quite standardized. But nothing like mixing multiple varieties of potato and reshaping them as fries.


You might be thinking of Pringles.


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

Search: