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

I've been working on a video game and actually followed the article to implement astar.

If you have an inaccessible node, astar will indeed scan everything. But to get around this I only had to add a limit to the number of frontier iterations which was just a conditional.


> The /bin/true (or /usr/bin/true) command is now nearly obsolete, because most extant shells now have a builtin "true" command. But it's still useful occasionally, for various silly reasons [...]

This make it sound like this is useless, but I disagree. For example, recently I had some games crash because they couldn't find pulseaudio, and making a symlink from pulseaudio to /bin/true fixed my issue (and yes, they had sound). So there are certainly legitimate uses for it.


Instead of a symlink to true you could have made an empty script.


And violate AT&T's copyright? Perish the thought!


Well the symlink command was also easier to share with others having the same issue, whereas a one liner that creates an executable script which returns 0 is less ideal.


An empty script returns 0 by default, thus `touch /path/to/missing/library` is a sufficient (and shorter!) one-liner fix to this problem.


I know, but you still have to make it executable, hence it's not as convenient.

And on top of this, an unlink is less error prone than a rm -f.


I question the same thing, and would like to know how accurate it is.

Is there any peer reviewed literature that supports this?


Somehow I can see some companies using this to spy on their employees and "measure" how productive they are, and how their timesheets reports match.


This is 100% where the tools-in-the-cloud thing is going. It's going to be a major selling point for a lot of buyers (companies).


I'm really surprised (and discouraged) to see how many people here are so enthusiastic about this. There is so much room for misuse. You're increasing your dependency on an external corporation, giving them more control over your development environment, giving up much of your autonomy, and somehow this is a good thing?

Development environments being overly complex to setup, long compile times, those are symptoms of software bloat and bad design, but instead of addressing these fundamental problems, people want compilation to happen externally on a 32-core machine so they can sweep those problems under the rug. Okay, let's see how that turns out.


Control for whom? Before gdpr the general stance in the industry was we never delete user data, just mark a field saying its deleted in the db and that's that. It's been a total shift.

And it's not just that, I've seen first hand that even internal communication about customers are treated with more care as they can legally request all their data.


Control for bureaucrats is the primary goal.

If there is some temporary marginal privacy benefit for users, it is a side effect.


For what is worth, I have disabled it in firefox 90 in about:config.


I did as well; Firefox 91 no longer has that option. You'll be Proton-ified if you upgrade.


I do too, but for about a month or so I've had proton anyway.

I use FF developer so I'm a bit ahead of everyone else.

You can fix it with some userChrome.css changes. I'm scared to touch it for fear of fucking my 'tabs on the bottom' css.


I think you would still be surprised at how many things emacs can still do better like undo in region or even simple macros that find use even during simple text edits.

Though ultimately feature per feature, I don't think emacs looks all that great, but the difference is that you can actually use a lot of what it has to offer whereas it's difficult to do so in more modern editors (with fuzzy matching and all).


> Debt repayment has one vital characteristic: it is easy to understand

If it were this easy you wouldn't see so many people taking on so many unnecessary debts. Technical or otherwise.


I'm in the process of searching for an apartment to buy and the formula for calculating the installment amount, while using only basic operations, is anything but simple.

Chiefly the answer to the question "how will this amount change if the interest rates go from effectively zero to 6%, which is the 30-year average?" is not straightforward.


I ignored systemd because I thought it didn't affect me, as I only run linux (fedora) on my desktop, and hardly had any issues at that.

But recently, when I changed my fstab file to mount a drive at boot, I made a typo. My system wouldn't boot at all and it wouldn't even drop to a shell so I can chroot the file system like you would with init.d.

I thought that there's some arcane command I don't know about. But there wasn't. You're locked off, and expected to boot off something else to fix your system. Horrible.

Having this said, I honestly expected way more on the section about benefits to users.


> But recently, when I changed my fstab file to mount a drive at boot, I made a typo. My system wouldn't boot at all

I don't know exactly what went wrong in your case, but killing Unix systems by messing with fstab has been a rite of passage for more than four decades. Systemd certainly didn't invent that. Hell, I broke a chromebook not 48 hours ago messing with the boot setup.

But FWIW: managing a recovery image is, amusingly, not historically a job systemd has tried to take on. This is what your live image is for.


I've been using linux on my desktop for almost 20 years. This was the first time I couldn't get a shell to fix my problem.


It sounds like what you ran into are the effects of the general trend of doing more in early boot, as https://freedesktop.org/wiki/Software/systemd/separate-usr-i... elaborates on, which is independent of systemd


Thanks for sharing this.


Atleast on Arch, Systemd should drop you into the Emergency shell if it cannot mount a device that isn't defined as optional. IIRC it might require a root password to be set, however.

Otherwise, edit the kernel commandline to add "systemd.unit=emergency.target" to the end, which triggers systemd to straight boot into this console without trying anything that it doesn't need to bring up the console.


Or if you're blocked by the root password prompt add `init=/bin/bash` and make your filesystem writable if necessary with `mount -oremount,rw /`


This will block systemd however. The nice thing about the emergency shell is that you can use systemd things like trying to mount filesystems. And you can later isolate multi-user to continue the boot when you finished your fix. /bin/bash would be atleast useful to try to get a root password set.


It tried when the mounting failed, saying it would drop me to a shell and then said "it fail to open up a shell".


That usually indicates something is very wrong and might need an init=/bin/bash instead, as a last resort, to find out why it couldn't open the shell (usually, because there is no root password or it couldn't find any shell binary to run).


Bare in mind that eu citizens still don't need a visa to travel to the uk.


"Bear in mind". "Bare in mind" sounds like you're thinking about the people naked.

:-)



I know that, and it's of course a good point.

I was trying to convey the fact that citizens from eu countries are not at the level of other third countries yet. For example you can still travel using just a national id card until October.

I wholeheartedly agree with the rest of your comment though.


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

Search: