Rust namespaces everything in the standard library to std:: or core::, and has a clear distinction between them.
However, it does implicitly include the entirety of the std::prelude namespace (https://doc.rust-lang.org/std/prelude/index.html) into every source file, as well as including every macro directly exported under std:: (including println!). This enables the unprefixed use of things like Result, Option, Some, Send, etc.
The prelude and std:: macros are the closest thing that Rust has to a global namespace, and even they can be disabled in crates that specifically request it.
If you want any evidence that terrible language design is alive and well in PHP, look no further than the new array_find function.
Not only is it yet another global function in a namespace already chock full of random array helpers, it is extremely similar in both name and usage to array_search - a global function since PHP 4. Except, of course, that in typical PHP fashion, array_find’s argument order is ($array, $filter_callback) while the older array_search is ($search_value, $array).
There are literally hundreds of hits for existing, global, functions named array_find. If these are loaded from a library, they will break uses of the new built-in function in exciting ways. Yet, even with this mentioned in the RFC (https://wiki.php.net/rfc/array_find) it seems to have been no obstacle whatsoever to its inclusion - despite the fact that the implementation is literally three lines of code.
I have to question if the benefits of this global function really outweigh the benefits. PHP devs claim that other languages have these functions so PHP should too - but neglect to note that most languages don’t make them global functions (rather, they’re usually array methods or in some utility module).
Your IDE should help you with the argument order if that's an issue for you. It has never been a problem for me and I don't understand the argument. I get that it might be confusing the few first times you use these functions, but if you use them every day you just remember the argument order.
The backward compatibility section found only 200-ish projects where array_find() was defined in global name space. For me that's a small price to pay for introducing the new function, and refactoring should BE easy when upgrading a project to PHP 8.4.
Adding array_find() to a namespace would be inconsistent. All other array_*() functions are global.
array_search() has the same needle, haystack order as in_array() or array_key_exists().
array_find() has a callback and takes the same order as array_walk() or array_filter().
It's just array_map() that's different, but that's because it can take multiple arrays.
And writing your own function with a prefix already used by PHP in the global namespace is just not a very good idea.
array_find parameter ordering is modeled after other non-variadic array functions, e.g. array_filter also having ($array, $callback) order.
But I agree, there is already some inconsistency, and when adding a new function you have to choose which function to make it consistent and which one to make it inconsistent with.
I had similar thoughts, but do appreciate the additional mb_ functions bringing multi byte support to some remaining functions.
Also people should be coding defensively with things like “if not defined” when implementing their own global helper functions (or avoid doing that at all)
"if not defined" doesn't help, if your own `array_find` doesn't have the same signature and semantics than the new global then you're screwed. You'd want the opposite: overwrite it if it already exists in the global scope (dunno if that's easy / how that'd work in PHP)
They could help by not adding any more cruft to the global namespace.
Adding any globals should be a carefully-considered change. User-defined functions are global by default, and although there are (now) much better ways to write PHP libraries, I can absolutely see some old library defining array_find (one of the new global functions in 8.4) in an incompatible way and breaking new code that attempts to use the built-in function.
Sure, you can’t touch the existing pile of globals, but at least stop pouring fuel on that particular fire…
That would be some really old library. Already in 2012 when Composer was released there was PSR-0 and today almost all libraries are Composer managed and using a namespace following PSR-4 which itself is ten years old. A library that old would almost surely not run on PHP 8 unchanged anyways.
Surrendering the global namespace to the language is not so bad an idea.
Suppose I want to add some new code to an old website? Or I want to gradually upgrade an ancient code base - twelve years is not so old for PHP, when ancient frameworks like Wordpress are still alive and kicking.
If we hitched language development on Wordpress we would still be on PHP4 as they refused to join gophp5 some seventeen years ago.
Again, an ancient enough codebase which contains a library using array_find will need enough upgrades to run on PHP8 much less PHP8.4 the change from array_find to something else is the least of your worries.
Seriously? 2k results for array_find in PHP on GitHub: https://github.com/search?q=array_find++language%3APHP&type=.... RFC authors (https://wiki.php.net/rfc/array_find) explicitly noted over 600 hits for definitions of array_find, around 30% of which are not false positives - that is, there's a good possibility that there are 200+ implementations of global array_find in just open-source projects.
There are so many more examples. Lots of the hits are from codebases that have seen updates in the last few years. Many more are plugins or other addons for PHP frameworks or apps which are still widely used (WordPress, phpBB, etc.).
This is because earlier reports coming out of law enforcement agencies suggested that the network was involved in making even older devices reboot. This blog post is an effort to debunk that claim.
Whenever you explicitly declare a lock ordering "B must be locked after A", it creates an (explicit) trait implementation "impl LockAfter<A> for B". It also creates a blanket (generic) trait implementation "impl LockAfter<X> for B" for any X where A implements LockAfter<X>; this basically fills in all the transitive edges of the graph.
Rust prohibits multiple implementations for the same trait and type. If there's a cycle in this graph involving A, then eventually the transitive walk will generate an "impl LockAfter<A> for A", after which it will generate a blanket "impl LockAfter<A> for B" which conflicts with the explicit impl and thus results in a compiler error.
You’re running desktop Linux - your whole system is permanently in “developer mode”. That’s kind of the point? Windows and macOS don’t have “developer mode” either, at least not to the extent seen in the mobile OSes.
Somewhat tangentially, I will say that Touch ID-based sudo is a real upgrade over password sudo. It still gives you that extra moment to reflect on whether you really want to run that command (unlike passwordless sudo), without being burdensome.
Honestly, sudo’s value is really sanity, not security.
The first time you use certain flavors of sudo, you get a nice little message which reminds you why sudo exists:
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
Realistically, sudo exists to remind a user of these points. That is: by needing to type “sudo” before a command, you’re being reminded to pay closer attention that you’re not violating another user’s privacy or doing something that’s going to break your system.
Sudo is so commonly used especially on developer machines that I think it is used reflexively without any thought at at all.
It should not be, but that's a different issue. It amazes me the amount of open-source projects that want to be installed with "sudo" when there is no reason they should not be able to be built and used entirely from within the developer's home directory.
I know more than one person who starts a shell session with "sudo -i" and then just works as root because typing "sudo" all the time is an annoyance.
I wonder if this comes from the how some developers view ops knowledge and tasks as merely ancillary to their interests and work.
For me, Linux was a hobby prior to and separately from programming. In the tutorials and documentation I read, every command was explained in detail and it was emphasized to me that I should never run a command that I don't fully understand. All instructions to elevate privileges were accompanied with advice about being careful running commands as root because root's privileges are especially dangerous. I was interested in those warnings, and took them seriously, because I wanted to master what I was learning. What I was learning, though, explicitly included Linux/Unix norms like security 'best practices'.
Developer documentation doesn't usually concern itself with Linux/Unix norms the way that tutorials for Linux hobbyists and novice sysadmins do. At the same time, the developers reading it might be perfectly dedicated to mastery, but just not really see what is considered proper usage by sysadmins (let alone the considerations that inform the boundaries of such propriety) to on-topic for what they're studying/exploring/playing with. Diving into those details might not be 'patt of the fun' for them.
What such a developer learns about sudo is mostly going to come from shallow pattern recognition: sudo is a button to slap when something doesn't work the first time, and maybe it has something to do with permissions.
But I think that comes from the mode of engagement, especially at the time of learning sudo, more than the mere frequency of use. I use sudo several times every day (including sometimes interactive sessions like you mention, with -i or -s), but I am careful to limit my usage to cases where it's really required. I'm not perfect about that; occasionally I run `sudo du` when `du` would suffice because I pulled something out of my shell history when I happened to be running it from / or whatever. But I certainly don't run it reflexively or thoughtlessly.
To be precise: you don't need to be in the sudo group, but in the lpadmin group. I'm not familiar with how Ubuntu groups are set up, but I guess it's likely that lpadmin is only granted to administrators by default.
That said, I'm guessing people aren't expecting lpadmin to mean a full privilege escalation to root.
There are two bugs here: one in cups, which allows it to chmod anything 777 (doesn't properly check for symlinks, or for the failure of bind), and one in wpa_supplicant, which lets it load arbitrary .so files as root. However, I suspect that even if these bugs are fixed, having access to lpadmin will still be a powerful enough primitive to escalate to root given the rather sizable attack surface of cups.
It became crystal clear that cups is a can of worms, and it would be prudent to completely replace it with with a new solution built from the ground up, ideally using modern tools and standards.
or just sandbox cups. There's no reason cups needs to write anything beyond its "configuration" and its "print spool". And hence, shouldn't have access to anything beyond what it needs to configure itself and print.
thing like cups should be easy to sandbox, especially if we allow dbus like APIs as a means to cross sandbox boundaries (i.e. RPC mechanism).
and by sandbox, I dont mean simply use apparmor type rules (though that can work), but a cups that lives within its own file system and nothing else is even visible.
i.e. programs will always be buggy, even if we get rid of all language oriented bugs, there will still be logic bugs that will result in security holes. We just need to make it easy to isolate programs (and services) into their own sandboxes while retaining the ability for them to interact (as otherwise, lose much of the value of modern systems).
In practice, I would argue, a lot of modern systems do this already (ala ios/android). The apps run sandboxed and only have restricted abilities to interact with each other.
That's sort-of the direction they're going with CUPS 3. The 'local server', which is what most people will need, runs as a normal user, not root, doesn't listen on the internet, and talks only the IPP everywhere protocol. For supporting legacy printers, there will be separate sandboxed 'printer applications' which read in IPP Everywhere, run the driver code, and communicate with the backend printer using an appropriate protocol.
For enterprise users there will be a separate 'sharing server'.
I'd prefer they make it the default to not install it. I don't need to print from Linux. I don't print from Windows nor MacOS much either. Less than once a year. But I particularly don't print from Linux. I suspect that true for most people. cups shouldn't be a default install IMO
How many percent is "most" people? What about enterprise users with complex setups/requirements, will they be supported or out-of-luck? Typically you'll have print servers with centralized authentication, possibly logging/auditing/billing, any this might depend on "the" component they'll leave out in the new product because, well, most people don't care about it...
> How many percent is "most" people? What about enterprise users with complex setups/requirements, will they be supported or out-of-luck? Typically you'll have print servers with centralized authentication, possibly logging/auditing/billing, any this might depend on "the" component they'll leave out in the new product because, well, most people don't care about it...
But the old, complex cups doesn't go away if a new, sandboxed version is developed, so the people who want the complexities can evaluate whether the security trade-off is worth it, and use it anyway if so.
What if you don't need cups because you don't print anything?
Just sudo apt remove cups right?
No, because cups is a dependency of the entire graphical subsystem, just removing cups also removes everything from the Nautilus file manager to Firefox to ubuntu-desktop itself.
This might be wrong, but based on my own experience of Ubuntu effectively uninstalling itself when I tried to remove a single package.
I think most of the default software gets installed as one large package group, rather than as individual pieces of software. Only the group is marked as manually installed, but the individual programs pulled in by that group are marked as automatically installed. If you try to apt install something you already have as part of the default distro software, you'll usually see a message saying something like "marked as manually installed."
When you go to uninstall one program from the group, that one program is uninstalled as requested, but the group itself has to be marked as uninstalled, since you've removed one of that group's "dependencies" and thus can no longer satisfy that group's installation requirements. You now have a load of software that was automatically installed as dependencies of another package, but are no longer dependencies of any manually-installed packages. The next time you run apt autoremove, it'll remove all of those automatically-installed components and leave you with an almost bare system.
However, it does implicitly include the entirety of the std::prelude namespace (https://doc.rust-lang.org/std/prelude/index.html) into every source file, as well as including every macro directly exported under std:: (including println!). This enables the unprefixed use of things like Result, Option, Some, Send, etc.
The prelude and std:: macros are the closest thing that Rust has to a global namespace, and even they can be disabled in crates that specifically request it.
reply