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

It's like predicting that flying will never be a mode of transportation while laughing about Wright brothers's planes crashing


I was thinking the same. But then I thought about it more and wondered why you need to enter your own password if you're already logged on. If an attacker is already in the system, it can install key logger and whatnot without the root password. And the xn--ts9h program can have the Unix permission so that only the user can run it.


Insider threat, attacker not in the system, you leave your terminal unlocked and are away. Someone walks passed and tries to install something from you terminal?


While it leads to slightly more chance of traceability, I've seen one line "curl | sh" which install a tool which transmit everything you type, or just your password (when you next type it) off to a remote server, so once you've left a terminal unattended you are in trouble anyway.

This is one place when windows can be much better, as users can't catch ctrl+alt+del, so you can always press that before logging in.


There is the mental function signalling "hang on, you're about to do something unsafe. Are you sure you want to do this?"

But I think there are some scenarios where it serves a practical security purpose as well:

- You're in an office, went away to grab a coffee and left the screen unlocked (bad!). Without sudo, a malicious person could indeed quickly install a backdoor or keylogger and take over your system.

- you're executing a third-party script on your user account. Without a password prompt, that script could trivially escalate its privileges by embedding sudo commands. With a password prompt, you'll hopefully stop and ask yourself why the script is asking for your password.

Basically, you actually cannot assuming that every running on a user account is really authorised by that user. So asking for the password is an attempt to reaffirm that it's really the user who gave that command.

> If an attacker is already in the system, it can install key logger and whatnot without the root password.

Yes, but that would require the attacker to, well, run sudo...


If I'm not mistaken, especially with x11, it is trivial to install a keylogger without root password. Just a process in the background that listen to your keys and send them over the wire. (And you can add that program in the list of program to run while logging in)


You need to enter your password so that software you run can’t give itself root privileges without permission


I don't understand this website and why it always get linked. It's just a list of a bunch of crates unsorted. Most of them are unmaintained, or just early prototypes. There isn't a good comparison of all these crates


We are not gui yet.


> I don't even understand how is that possible, since Qt Creator is GPL3.

Because doing so would be violating the terms of the commercial Qt license you paid for.


Regarding the sloc count, the default automated Rust formating tool is very eager to adds lot of lines by basically keeping only one word per line. Something I'm not a fan of, I must say.


It usually does that on iterator chains, which AFAIK do not exist as such in C++, so multiple operations would be expressed as multiple imperative statements.

My C++ is rusty (no pun intended) but I struggle to imagine their variant of `vector.iter().map().collect()` to be as concise and fit in fewer than 4 lines.

I wonder if OP's C++ port doesn't use iterators that much, and how idiomatic it is.

EDIT: the code is not idiomatic at all.


> I wonder if OP's C++ port doesn't use iterators that much, and how idiomatic it is.

I think I only used iterators in places where there's no built-in function on slices like C++'s strchr and strspn. (I think Rust's str has these, but not [u8].) For example:

C++: https://github.com/quick-lint/cpp-vs-rust/blob/f8d31341f5cac...

    std::size_t length = std::strcspn(c, separators);
    if (c[length] == '\0') {
      return found_separator{.length = length,
                             .which_separator = static_cast<std::size_t>(-1)};
    }
    const char* separator = std::strchr(separators, c[length]);
Rust: https://github.com/quick-lint/cpp-vs-rust/blob/f8d31341f5cac...

    match s
        .as_bytes()
        .iter()
        .position(|c: &u8| separators.contains(c))
    {
        None => FoundSeparator {
            length: s.len(),
            which_separator: INVALID_WHICH_SEPARATOR,
        },
        Some(length) => {
            let found_separator: u8 = unsafe { *s.as_bytes().get_unchecked(length) };
            match separators.iter().position(|c: &u8| *c == found_separator) {


Of course it exists in C++, and has done since before Rust even existed.

Syntax is usually `vector | map | collect`.


> Of course it exists in C++, and has done since before Rust even existed.

Not in C++'s standard library until C++20.


Things don't need to be standardized in an ISO document to exist and be readily available.

I remember using it as early as 2008.


Wow, my C++ knowledge is even worse than I thought. I didn't know it had "pipelines".

https://en.cppreference.com/w/cpp/ranges


It's not "pipelines". It's just an overloaded bitwise-or operator.


> It usually does that on iterator chains, which AFAIK do not exist as such in C++, so multiple operations would be expressed as multiple imperative statements.

https://en.cppreference.com/w/cpp/ranges

Before C++20, similar functionality has been available in boost.


> the default automated Rust formating tool is very eager to adds lot of lines by basically keeping only one word per line.

This is not my experience.

Lifetime and '&mut self' noise (and four-space indentation) did cause rustfmt to sometimes split function signatures across multiple lines, but overall, I think rustfmt did a good job.

C++: https://github.com/quick-lint/cpp-vs-rust/blob/f8d31341f5cac...

    lexer::parsed_identifier lexer::parse_identifier(const char8* input,
                                                     identifier_kind kind) {
      const char8* begin = input;
      const char8* end = this->parse_identifier_fast_only(input);
      if (*end == u8'\\' || (kind == identifier_kind::jsx && *end == u8'-') ||
          !this->is_ascii_character(*end)) {
        return this->parse_identifier_slow(end,
                                           /*identifier_begin=*/begin, kind);
      } else {
        return parsed_identifier{
            .after = end,
            .normalized = make_string_view(begin, end),
            .escape_sequences = {},
        };
      }
    }

Rust: https://github.com/quick-lint/cpp-vs-rust/blob/f8d31341f5cac...

    fn parse_identifier(
        &mut self,
        input: *const u8,
        kind: IdentifierKind,
    ) -> ParsedIdentifier<'alloc, 'code> {
        let begin: *const u8 = input;
        let end: *const u8 = self.parse_identifier_fast_only(input);
        let end_c: u8 = unsafe { *end };
        if end_c == b'\\'
            || (kind == IdentifierKind::JSX && end_c == b'-')
            || !is_ascii_code_unit(end_c)
        {
            self.parse_identifier_slow(end, /*identifier_begin=*/ begin, kind)
        } else {
            ParsedIdentifier {
                after: end,
                normalized: unsafe { slice_from_begin_end(begin, end) },
                escape_sequences: None,
            }
        }
    }


I mean, there might be effect, but do you have a quantification of these. Like maybe you get 0.1% more likely to catch cancer if you eat these mushroom, but when you compare that to the 300% more likely if you smoke then I think you're safe.

Why do we allow smoking but are scared of low dose radiations?


"Why do we allow smoking but are scared of low dose radiations? "

Because smoking is not mandatory for everyone, but a individual choice and you can sue people, whose smoking effects other people.

Radiation effects everyone.

And no one is scared of low dose radiation, but it is a symptom of what can happen.

Chernobyl was just one incident. Going 100% nuclear and with people still being people, this would mean more accidents, more radiation, more cancer.


>Radiation effects everyone.

So do emissions and by-products of mining, coal burning, battery tech. To a much higher extent if I may add.


> 150k people had to leave their homes because they were not safe.

The fact that they were not safe is disputed. There are claim that there was some over-reaction and that the evacuation was actually counter-productive.


In retrospect there's no doubt the evacuation was an overreaction. Of course, in the moment, it's a harder decision since you have to act on incomplete information.


David Jiménez Ex Director of the Spanish Newspaper El Mundo was there in Fukushima. In one of his commentaries (extracted mainly from his interview in the podcast of Jordi Wild) explains that he encountered rescuers who showed him Geiger instruments measuring unsafe levels of radiation.

And a really gossip comment comes from JDM car lovers that have gone to Fukushima and show abandoned cars with again unsafe radiation levels.

It is not easy to react to a possible nuclear disaster after a heavy earthquake anyways.


Unsafe based on standards made incredible extreme because of the anti nuclear movement in the 70s based on false science.

This was the great trick the environmental movement bulled, they made so much panic about radiation that acceptable amounts were lowered to absurd levels. This was all based on suds-science. If this science were even remotely true, people in Denver would by dying of cancer at incredible rates.

There are also lots of places that have more radiation because sand beaches (historically associated with healing sands). People living in that region for 100s of years should also suffer from higher cancer rates and don't.

There are still people in Germany flipping out about the fact that some mushrooms have 'unsafe levels of radiation' and yet lots of people eat them and it has no effect what so ever.


the limits are purposefully set -below- the level at which unacceptable risk of biological impact.

that is quite logical, scientific and consistent with approaches taken in relation to other biological hazards.


Yes, of course the limits are below "dangerous" levels. That, in itself, says nothing about what we should call "safe" levels.

Radiation has two types of dangers, chronic and acute. Our understanding of what levels of radiation cause acute damage is pretty limited and not very precise since we simply don't have that much data. However, I highly doubt that anything close to those levels of radiation were measured anywhere outside the reactor complex.

In terms of chronic danger, the official stance is that there is no safe amount of radiation exposure and the general principle in managing exposure is ALARA (As Low As Reasonably Achievable). Lifetime cancer risk is cumulative so higher levels just add to that cumulative risk faster.

Thus there isn't really a clear "level of acceptable impact" but rather, we set arbitrary levels to to to limit that cumulative addition of cancer risk. Like with many things, that risk is a price you pay for other things that are important to you, like flying, living in denver, or getting xrays.


No, the limits are set below natural background radiation in many inhabited places on earth (Ramsar, Guarapari).


For GUI programming, you can use a toolkit that have a preview extension that updates in real time as you type. For example, Slint does that.


It doesn't do that for Rust code being called from UI.


Yes that's right. The thing is that people have been using the term OCD as a pejorative term for someone who is "detail oriented" and that need to be avoided. (When not referring to the disorder specifically)


I think it's the same reason why we are teaching assembly even if there are compilers. Or teaching Latin even though it's a dead language


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

Search: