Overclocking the Raspberry Pi 4

The Raspberry Pi 4 single-board computer is, as our review demonstrates, something of a beast relative to its predecessors. But there’s a way to get even more performance out of it -- or any other model of Raspberry Pi, for that matter: boosting the CPU and GPU clock speeds through overclocking.

(Image Credit: Gareth Halfacree)(Image Credit: Gareth Halfacree)

Overclocking a Raspberry Pi: What You Need to Know

While overclocking a Raspberry Pi 4 is, on the face of it, as simple as editing a configuration file -- and doesn’t even void your warranty, unless you take it to extremes -- there are a few things you need to know before you get started.

You’ll need a good-quality power supply. A third-party supply which works fine on a Raspberry Pi 4 running at stock clock speeds won’t necessarily keep up with the demands of an overclocked unit. Either pick up the official Raspberry Pi Power Supply or a quality unit from a trusted third-party manufacturer, and keep a close eye out for a lightning-bolt symbol at the top-left of the screen: That’s a warning your Raspberry Pi is being starved of power.

You’ll likely need active cooling. While it’s not completely necessary, especially if you’re only experimenting, the Raspberry Pi 4 runs hot. A small passive heatsink, available from almost any Raspberry Pi stockist you care to name, is better than nothing, but adding a fan for active cooling is better still. Teeny-tiny fans, powered by the GPIO header, are available but relatively rare and expensive; a cheaper option may be to look at third-party cases which include mounts for a larger fan, or the official Raspberry Pi Power-over-Ethernet (PoE) HAT accessory which has its own PCB-mounted fan. If you don’t cool the Raspberry Pi 4, you won’t damage it but it will hit its thermal throttle point quickly, negating the point of overclocking it in the first place.

You don’t need to worry about your warranty. Every Raspberry Pi comes with a software-set ‘fuse’ in its system-on-chip (SoC) which trips only when two key features are set: One sets the core voltage above recognized-safe levels, the other forces the CPU to run at its maximum speed at all times. Avoid the use of the latter -- the force_turbo option -- and your warranty is safe.

Overclocking the CPU

Most workloads on the Raspberry Pi are tied to the clock speed of the central processing unit (rather than the graphics processing unit) of the SoC, making it the obvious place to start experimenting. To begin, you’ll need your Raspberry Pi 4 and accessories plus a microSD card with a copy of NOOBS - the New Out Of Box Software - compatible with the Raspberry Pi 4. If in doubt -- and particularly if you’ve used older models before -- download a fresh copy of NOOBS from the Raspberry Pi website.

The reason for using NOOBS, rather than a straight Raspbian installation, is simple: NOOBS includes the ability to edit the configuration files in the /boot directory even if Raspbian can’t load. If something gets messed up and your Pi won’t boot, just hold down the Shift key on startup to go into the NOOBS Recovery Mode and edit the configuration file from there.

The majority of the core configuration settings for a Raspberry Pi can be found in a file helpfully called config.txt in the /boot directory. It’s a standard text file, and you can open it in a variety of ways: Double-clicking on it in Raspbian is enough to show you its contents, but not to let you save any changes you make. For that, you’ll need elevated privileges. Open a Terminal with Control, Alt, and T, then type:

sudo nano /boot/config.txt

This opens the file in the Nano text editor with root-level privileges -- equivalent to the Administrator account in Windows. Using the cursor keys, scroll to the bottom and find the section marked [pi4], which contains settings loaded only when the microSD is running in a Raspberry Pi 4. If you’re overclocking a different model of Raspberry Pi, just head to the bottom of the file.

On a new line under [pi4], type the following:

over_voltage=2
arm_freq=1750

The first of these settings, over_voltage=2,increases the voltage provided to the SoC by around 0.05V; it’s not much, but without this extra little boost it’s unlikely you’ll be able to boot your Raspberry Pi 4 at its new, higher clock speed.

The second setting, arm_freq=1750, sets the clock speed of the SoC’s four Arm Cortex-A72 processor cores to 1,750MHz or 1.75GHz, an increase of 250MHz over the stock 1.5GHz setting. At the time of writing, that was as high an increase as possible: Anything over 1,750MHz actively harms performance. Post-launch, firmware updates may increase this limit as far as 2GHz for those with adequate cooling.

Save the changes with Control and O, then exit Nano with Control and X. You’ll need to reboot the Raspberry Pi 4 to reload the new configuration file, which you can do by typing:

sudo reboot

If all has gone well, Raspbian will load as normal; if not, hold Shift to load the NOOBS Recovery Mode and try increasing the over_voltage setting or decreasing the arm_freq setting. Note you can’t increase over_voltage above a value of 6 -- equivalent to a 0.15V increase to core voltage -- without using the force_turbo setting and voiding your warranty.

Benchmarking a CPU Overclock

Overclocking the Raspberry Pi 4 isn’t just about tweaking a configuration file; it has a real impact on actual workloads and synthetic benchmarks alike.

The Linpack benchmark offers a look at floating-point performance: Both the single-precision and double-precision modes see a 16-18 percent performance boost with the overclock active, while a single-precision version which makes use of the Arm cores’ NEON acceleration instructions is lifted by roughly 15 percent.

A real-world file-compression test, in which a large file containing random data is compressed using the single-threaded bzip2 and multi-threaded lbzip2 compression utilities, shows a somewhat smaller gain at around 9 percent faster single- and 7 percent faster multi-threaded.

An image editing benchmark, built using the popular open-source GIMP software, benefits more from the boosted CPU clock speed: finishing in 39.2 seconds compared to 47.35 seconds on a stock-clocked Raspberry Pi 4, it shows an impressive 17.2 percent gain.

Even web browsing is improved: The Speedometer 2.0 benchmark, which measures web-app responsiveness, is boosted by around 11 percent with the new clocks.

Not everything benefits from the new clock speed, though. The OpenArena first-person shooter, based on id Software’s Quake III Arena, sees only a margin-of-error difference in framerate. Applications like this are typically GPU-limited, rather than CPU-limited; to improve the performance here, the GPU needs some attention.

Overclocking the GPU

Overclocking the Raspberry Pi 4’s GPU is no more difficult than overclocking its CPU, and is controlled using the same configuration file as before. Open a Terminal with Control, Alt, and T, and type:

sudo nano /boot/config.txt

Scroll down to the [pi4] section, as before, and add the following line:

gpu_freq=600

Where the arm_freq setting controls the CPU clock speed, the gpu_freq setting unsurprisingly does the same for the GPU clock speed. The default is 500MHz; 600MHz offers a modest performance boost without much risk, and again keeps your warranty intact.

You’re likely to find overclocking both the CPU and GPU is too much for your overvoltage setting: find line which reads over_voltage=2 and change it:

over_voltage=4

Save the file with Control and O and exit Nano with Control and X. Reboot the Raspberry Pi 4, and all should be fine; if Raspbian doesn’t load, hold Shift to go into the NOOBS Recovery Mode and edit the configuration file to increase over_voltage to 6.

Don’t try to increase the over_voltage setting any further than 6; values above this are ignored unless you also set the force_turbo setting, and doing so toggles a fuse in the SoC which invalidates your warranty.

Benchmarking a GPU Overclock

You’d think there’s little point in running any of the CPU-based benchmarks again to see how the GPU overclock affects them, in much the same way as running the GPU-based OpenArena benchmark was pointless following the CPU overclock. You’d be wrong, however: the Raspberry Pi’s GPU enjoys considerably more control over the system than you might expect, thanks to the SoC’s origins as a multimedia chip for set-top boxes and entertainment systems.

The Linpack benchmark demonstrates this well: The single-precision performance has increased yet again, boosted to nearly 20 percent over the stock Raspberry Pi 4 compared to just 17 percent on a CPU-only overclock. The double-precision gains are somewhat lower, but the NEON-accelerated performance is again almost 20 percent higher compared to the 15 percent uplift of the CPU-only overclock.

There’s no such thing as a free lunch, of course, and the real-world file compression test tells a different story: The single-threaded benchmark shows no change over the CPU-only overclock, while the multi-threaded version has dropped from the previous 6.7 percent gain to just 1.3 percent.

For image editing there has again been a loss of performance: the 17.2 percent uplift obtained from the CPU-only overclock has dropped to 6.6 percent, adding a full three seconds on to the completion time.

When it comes to web browsing, the story is somewhat happier: the 11.2 percent performance gain measured on the CPU-only overclock is boosted slightly to 12.4 percent, and while that’s only a minor gain, it is at least not the losses seen in other tests.

Where the GPU overclock shines is, unsurprisingly, in the OpenArena gaming benchmark. Switching the GPU clock to 600MHz from its stock 500MHz boosts the game’s framerate 16.4 percent from 41.4 frames per second to 48.2 frames per second.

Conclusion

The Raspberry Pi 4 is already a powerful device, easily beating its predecessors and its similarly-priced competition in a range of benchmarks. For those who need still more, though, overclocking is a quick and easy way to wring a little extra performance for both CPU and GPU workloads - though you’ll have to decide which of the two is most important to you in order to realize the biggest gains, and additional cooling is highly recommended.

Post-launch firmware updates may increase the current 1.75GHz CPU clock speed cap, too, allowing for still more performance gains to be realized -- and all without invalidating your warranty.

Image Credits: Tom's Hardware

13 comments
    Your comment
  • derekullo
    Mmm this rasberry pi smells delicious.

    Be careful not to burn the crust. :P
  • Giroro
    "Double-clicking on it in Raspbian is enough to show you its contents, but not to let you save any changes you make. For that, you’ll need elevated privileges. Open a Terminal with Control, Alt, and T, then type: "

    How is it that in 25+ years of Linux development, they still haven't figured out a better way of making the GUI integrate with the terminal in an actually-useful way.... Or for that matter come up with a normal way of editing text. Editing text through a terminal is a -REALLY BAD- user experience, and linux is -still- virtually unusable without using the terminal every 5 seconds and re-navigating over and over to wherever you hit a roadblock in the GUI.
    Just let people 'run as root' or whatever from the GUI. Or at least let us directly open a folder in the terminal from the GUI? Windows figured that out in, like, 1995. It really doesn't need to be this hard.

    I rant about this, because in my first (and probably last) outing with Raspbian, it took me over -2 hours- to make a 1-line change to config.txt. It was a gigantic mess of disparate tutorials insisting the GUI text editor can actually save config.txt, getting sent to a smattering of poorly documented terminal text editors which tell you to save the file but don't give any indication on how to save a file without a menu... and way too many recommendations to just plug the microSD card into a normal computer and edit the file with Windows (my personal favorite)....If anybody would ever consider recommending you use a totally different OS just to edit a text file, then maybe the OS (still?!) isn't ready for prime-time guys.

    Pointlessly complicated stuff like that is why Raspberry Pi appeals to a small niche of adult hobbyists, but never really caught on for it's original intended purpose of teaching kids to program python. I'm an engineer, and I still had my "forget this, I'd rather pull out a MCU and write bare-metal Assembly" moment.
    If you really are stuck trying to use a linux computer to control hardware, do yourself a favor and just use the root account for everything.
  • bit_user
    Thanks for this article, but a few points:
    • Please specify the exact model of heatsink-fan you used, as well as the thermal compound.
    • I wish you benchmarked stock w/o heatsink, stock w/ heatsink, and OC w/ heatsink. As the original article showed, the SoC will thermally-throttle even at stock speeds. So, it would be nice to see what advantage can be obtained simply by virtue of adding the heatsink-fan.
    • I wonder if the reason the GPU overclock hurt CPU benchmarks is due to generating more heat, so the CPU throttled sooner. To confirm this, it would be nice to pair temperature plots with the tests.
    • Please start your graphs at 0. I was shocked at what a big difference the overclocking made, until I noticed that some of the graphs didn't start at zero. Then, I felt cheated.


    Again, thanks. Please consider these points, and maybe do a follow-up article.
  • bit_user
    Quote:
    If you really are stuck trying to use a linux computer to control hardware, do yourself a favor and just use the root account for everything.

    Really bad advice.

    It's easy enough to use sudo. If you need to type a string of commands, you can even run "sudo su", to get a root shell session.

    I can give at least 3 good reasons not to run as root, when it's not necessary.
    • Greater risk of breaking your system. When running as root, you can delete or overwrite almost anything. This makes it much more accident-prone.
    • Security risks - if you fall victim to a remote execution exploit (i.e. via a browser or some malware or security flaw in a program you're running), then this gives the attacker 1-step control of your system. Otherwise, they need to pair a remote execution exploit with a privilege escalation exploit.
    • Likely messing up of permissions on files that you want or need to access, when running as a normal user.

    Therefore, it's strongly advised only to use root/sudo specifically for tasks that require it.

    Back in the days of Windows XP, one reason Linux had a tendency to be more secure was that most XP users would run with admin privileges, whereas Linux users almost never do. MS took the clue and markedly improved security, when they started prompting for every operation requiring admin privileges in Windows Vista and beyond.
  • k1664
    Quote:
    I'm an engineer,

    Quote:
    in my first (and probably last) outing with Raspbian, it took me over -2 hours- to make a 1-line change to config.txt


    As convoluted as Linux can be, even though a great deal of it is for security to ensure people don't take your advice of running as root all the time, I feel good that as a non-engineer it took me less than 10 minutes to edit the same config.txt file.
  • Giroro
    Quote:
    As convoluted as Linux can be, even though a great deal of it is for security to ensure people don't take your advice of running as root all the time, I feel good that as a non-engineer it took me less than 10 minutes to edit the same config.txt file.


    Hey props to Tom's for at least including the tutorial step that was actually a working way of doing it. There's a lot of bad info out there in the top search results.

    But the security argument, I'm not so sure about that. Or, actually moreso:
    Quote:
    Greater risk of breaking your system. When running as root, you can delete or overwrite almost anything. This makes it much more accident-prone.


    Has there been any scenario where a Linux user had a command fail where they didn't immediately attempt the exact same thing again with a sudo in front?
    I'm really asking, linux users, have you ever thoughtfully considered if you made a mistake before you add on that sudo, or do you just immediately retry? For people who really do need that kind of protection from themselves, why make them retype the entire command every time instead of a single character "Are you sure Y/N".. That's what always bothers with me linux, it deliberately uses the hardest and slowest ways of forcing users into its philosophy. Even when users agree with it they are still getting punished. Unless of course there actually is a way to use sudo through the GUI.
    It feels more like training users to instinctively ignore the 'safeguard', so why not cut out all the added steps?

    Quote:
    Security risks - if you fall victim to a remote execution exploit (i.e. via a browser or some malware or security flaw in a program you're running), then this gives the attacker 1-step control of your system. Otherwise, they need to pair a remote execution exploit with a privilege escalation exploit


    Is this really that big of a concern for most Raspberry Pi projects? There's (a lot) of better options for surfing the web or as a normal desktop environment. I mostly see single-use offline hardware projects and retropie boxes with limited/no interaction with the terminal to get things running.

    Quote:
    Likely messing up of permissions on files that you want or need to access, when running as a normal user.

    But why would you ever go back to running as a normal user, when that's the problem in the first place?

    ----

    Anyways, I get it, Linux devs want to keep things overly difficult/slow/complicated to keep the normies out. I would have just hoped that the Pi specific flavor would have figured out how to make things easier for their target audience of hobbyists and children than Fedora 10. The aging dev community needs to put some real thought into the future of Linux. There are kids these days raised on Android and iOS that not only don't know what a terminal is, they don't even really know what a folder is. They need more on-boarding than being forced into a deliberately obtuse linux terminal if you ever want them to someday start developing for it (and by extension, funnily, android).
  • bit_user
    Quote:
    Has there been any scenario where a Linux user had a command fail where they didn't immediately attempt the exact same thing again with a sudo in front?

    From an experienced user: yes! I know which commands are likely to need root, but I'm not 100% sure about a few. So, I do sometimes try a command without sudo, before I try it with. Furthermore, I know which commands are likely to cause persistent modifications to my system. For the novice, this can obviously be more difficult.

    Fortunately, some newer Linux filesystems have snapshotting features, which is like an instantaneous backup of your filesystem. This allows one to be a bit more adventurous, as long as you don't break it too badly and you actually know how to revert to a recent snapshot.

    Linux GUIs are also better than they used to be, but I'm too old-school to follow these developments closely. The biggest problem is they tend to be too dumbed-down. However, a lot of things that would previously force users onto the commandline no longer do. Thank goodness I never have to fight with X Windows config, for instance.

    Quote:
    For people who really do need that kind of protection from themselves, why make them retype the entire command every time instead of a single character "Are you sure Y/N"..

    Um, what are you talking about? You can just hit the up arrow and edit the commandline to insert "sudo" at the front.

    And asking "are you sure" doesn't confirm either that the user has the authority to execute admin commands or do anything to confirm the user's identity. "sudo" is really a way of granting elevated priviliges to a set of users, but it can also restrict the types of operations to which this applies. So, you want to confirm the identity of the user and it needs to know to which command it's being applied.

    Quote:
    That's what always bothers with me linux, it deliberately uses the hardest and slowest ways of forcing users into its philosophy.

    No, Multics was the hardest way of doing things. UNIX was designed as a simpler alternative.
    ; )

    But I will agree with you on one small point, which is that UNIX was designed for a multi-user environment, where you also have a knowledgeable administrator. Sometimes, the multi-user baggage gets in the way. However, Windows has this too, as well as the idea of a super user.

    Quote:
    Unless of course there actually is a way to use sudo through the GUI.

    A lot of GUI-based administrative programs will pop up an authentication dialog, when you need to do something requiring admin privileges.

    Quote:
    Is this really that big of a concern for most Raspberry Pi projects? There's (a lot) of better options for surfing the web or as a normal desktop environment. I mostly see single-use offline hardware projects and retropie boxes with limited/no interaction with the terminal to get things running.

    In the age of cyber crime and cyber terrorism, even IoT cannot afford to skimp on security.

    I would agree that many projects could do with a thinner, lighter OS, but that would simultaneously render the machine unsuitable for desktop-style use. So, a full-blown OS is definitely called for by the range of uses that the Pi Foundation sought to address.

    Quote:
    But why would you ever go back to running as a normal user, when that's the problem in the first place?

    See points #1 and #2, in my previous post.

    Another reason would be on a system shared by multiple users - if you start using root for everything, you risk a scenario where you start messing up permissions and ownership on things, eventually forcing everyone to use root. At that point, it becomes a shared, single-user system and you might as well go back and use DOS and Windows 3.1.

    Sometimes, I even make a dedicated account for certain automated processes. This is actually pretty standard practice, as you can see by reviewing all of the accounts on your system (hint: look at /etc/passwd).

    Quote:
    Anyways, I get it, Linux devs want to keep things overly difficult/slow/complicated to keep the normies out.

    It sounds to me like you're extrapolating far too much from one bad experience.

    I'd agree that Linux usage is not always smooth sailing, but then I am something of a power user.

    Something to keep in mind is that Android/ChromeOS are Linux-based. Macs are BSD-based. Microsoft is moving closer and closer to Linux, every year. Google, Facebook, and Amazon all use Linux. IBM bought Redhat. Many governments are now using Linux. They must know something, eh?
  • bit_user
    Quote:
    Hey props to Tom's for at least including the tutorial step that was actually a working way of doing it.

    Also, did you see this?

    https://www.tomshardware.com/reviews/raspberry-pi-command-line-commands,6159.html

    It's a somewhat random smattering of tips and "Intro to the commandline". Probably worth a read, if you ever have another occasion to fire up the terminal.

    I'm not saying it's the best out there, but it's a place to start & might have the info you need.
  • AllanGH
    Quote:
    ...Just let people 'run as root' or whatever from the GUI...

    Disallowing a root GUI session is actually a "fairly recent" move in Debian (what Raspbian is based upon), and that's a good move on the part of the devs. It's not worth delineating the benefits of the change, since you don't seem to view the development goals as legitimate.

    It's easy to make config edits to restore the ability of root to login to a local X session, and despite trying the mods to see if they work (they do), I don't see it as a necessary change. Any administrative task that can be done through X can be done faster and easier through the CLI...it's a time saver, far more efficient and powerful than hunting around a bunch of menus with a mouse pointer.

    Quote:
    ...they still haven't figured out a better way of making the GUI integrate with the terminal in an actually-useful way...

    As to accessing the console, CTRL+ALT+F1 will switch you to tty1 and you can login. You can CTRL+ALT+F7 to switch back to the running X session. Switch back and forth as much as you like, then exit the console session and go back to X.

    Need multiple console sessions? CTRL+ALT+F[x]; (1 ≤ x ≤ 6)

    This ignores the fact that you can open multiple terminals from within an X session, and have separate concurrent console sessions running under the same username. Enable multiple virtual desktops, and put each terminal session on its own desktop. Like magic...things are organized for an extended task, or series of tasks, and you switch desktops with a roll of the mouse scroll wheel.

    That is useful.

    Quote:
    ...Anyways, I get it, Linux devs want to keep things overly difficult/slow/complicated to keep the normies out...

    No. You really don't get it.

    Nobody is excluding...LOL..."normies" from anything. All a person has to do is learn to use the tools provided by the OS; and, not to mention the man pages, the Internet is filled with documentation and HOW-TOs. After all, learning is just reading and remembering--easiest thing in the world to do--but nobody is going to hold your hand and spoon-feed you the knowledge. If you don't want to take the time to learn something...well, that's self-imposed exclusion, if you ask me.

    You still have windows, so you don't have to join the legions of victims being punished by those demonic Linux devs.

    Quote:
    ...it took me over -2 hours- to make a 1-line change to config.txt....

    Helpful reading for those who need to learn about BASH:
    http://www.tldp.org/LDP/Bash-Beginners-Guide/Bash-Beginners-Guide.pdf
    http://www.tldp.org/LDP/abs/abs-guide.pdf

    It is unfortunate that Linux isn't the way you want it to be, but you aren't going to see anybody apologizing to you because of that. You aren't used to using anything except windows. Fine, but please don't rant about "fixing" what isn't broken, because you don't understand it; and don't wring your hands over Linux not being like windows--it's not supposed to be.
  • Giroro
    Quote:
    Um, what are you talking about? You can just hit the up arrow and edit the commandline to insert "sudo" at the front.

    That's good to know.

    Quote:
    And asking "are you sure" doesn't confirm either that the user has the authority to execute admin commands or do anything to confirm the user's identity. "sudo" is really a way of granting elevated priviliges to a set of users, but it can also restrict the types of operations to which this applies. So, you want to confirm the identity of the user and it needs to know to which command it's being applied.

    The content of the message isn't important, It can just as easily say "Retry that last command with elevated privileges Y/N" The point is that there is a lot more that can be done to make the user's life easier without actually changing what's happening behind the scenes. Although I'm not sure how typing sudo confirms the user's identity when non-root accounts are allowed to use it.

    Quote:
    In the age of cyber crime and cyber terrorism, even IoT cannot afford to skimp on security.

    What I was getting at there, is that a lot of hardware focused Pi projects don't need to be online, at all. The older/cheaper boards don't even have WiFi. The best cyber security is to never connect to the internet in the first place.

    Quote:
    It sounds to me like you're extrapolating far too much from one bad experience.


    I've tried various flavors of Linux about a dozen times over the last 15 years or so. Compared to previous experiences my time with the Pi was relatively positive. Software actually installed the way it was supposed to, I didn't have to compile anything (except the code I was running to run an LED array over SPI), and everything was easy to install and sandboxed from my normal computer.
    It's just that editing one config file and running some pre-written could should not have taken an entire day. It's frustrating to know you have to give up on a project because some hardware evaluation that should have taken 6 hours beginning-to-end ended up taking 8 hours just to follow a 3-step Pi-specific tutorial to get the demo code running.

    Quote:
    No. You really don't get it.

    Well actually, I do.
    Reading the rest of your post, it's a typical example of the exact thing I'm complaining about. Linux power users complaining about Windows without realizing that they're failing to provide an alternative that somebody can learn in a reasonable amount of time. "Git Good" or any variation of that sentiment is off-putting, and doesn't actually do anything to fix the glaring problems with the user experience. Nor does it actually encourage anybody to actually put forth the effort. I WANT to like linux, but it is far from perfect and absolutely is not friendly to new users. I get the feeling you're in it so deep that I don't think you realize nothing you said actually means anything to somebody who doesn't already know what you're talking about (and tbh I'm probably not going to look up any of those acronyms, out of spite). FWIW, you lost me at "It's easy to make config edits ..." because that fact that it was actually pretty hard to learn a way to make a config edit was the reason I was complaining in the first place.

    Quote:
    Helpful reading for those who need to learn about BASH: http://www.tldp.org/LDP/Bash-Beginners-Guide/Bash-Beginners-Guide.pdf

    Quote:
    Prerequisites/not in this course: ·You should be an experienced UNIX or Linux user, familiar with basic commands, man pages and documentation · Being able to use a text editor · Understand system boot and shutdown processes, init and initscripts · Create users and groups, set passwords · Permissions, special modes · Understand naming conventions for devices, partitioning, mounting/unmounting file systems · Adding/removing software on your system"


    I don't know what BASH is, but it sounds too advanced for me. If I read (what I assume is another 175 page book) and then read this 175 page book.. will any part of that actually help with Pi hardware development? If learning the OS takes longer than the (electronics) project itself, then I feel like the OS hasn't actually done it's job. It should be there to speed up development, not to impede it.

    Raspberry Pi isn't targeted toward linux power users. People who are only interested in using Linux as a desktop OS can just install it on their current computer for free. I wanted to use what was sold to me as a cool STEM toy to make some lights blink.
    Honestly, I don't think my experience is atypical either; I imagine most people picking one up don't have any linux experience at all. That is why I feel that Raspbian could be doing more to get the OS out of the way of users who are primarily interested in the GPIO.
  • bit_user
    Quote:
    I'm not sure how typing sudo confirms the user's identity when non-root accounts are allowed to use it.

    sudo is usually configured to prompt for password. Forcing re-authentication is what confirms the user's identity.

    When executing a series of commands, in rapid succession, you can also suppress the password prompt.

    Quote:
    a lot of hardware focused Pi projects don't need to be online, at all.

    That's a small minority of users. The Pi was designed to be a modern, cheap computer, first and foremost. In order to install packages, updates, use github, etc. you really need to be online.

    Sure, you could make a custom image, burn it to SD card and never connect it to a network, but that's just not the reality of how they're used.

    Quote:
    The older/cheaper boards don't even have WiFi.

    Because there are USB wifi adapters, and they're pretty cheap.

    Quote:
    The best cyber security is to never connect to the internet in the first place.

    I think that option really stopped being viable somewhere in the early 1990's. ...or, I could suggest that perhaps you lead by example!
    ; )

    It's like saying: the best way not to have your car stolen is not to have one. Well, that's fine if you don't need one, but it's really of no help to the majority who do.

    Quote:
    It's just that editing one config file and running some pre-written could should not have taken an entire day.

    What I don't understand is why this became an indictment of Linux, writ large? Why wasn't this a specific complaint that the Pi should have a GUI front-end for that config file?

    Somehow, I feel like if the same sort of thing happened on Windows, you'd focus on the specific task, rather than trying to use it as an example of what's wrong with the entire Windows architecture and ecosystem.

    And, TBH, Windows has plenty of arcane bits, too. Sometimes, I find myself following instructions from a web site and really delving into some dark corner of Windows I don't know at all.

    Quote:
    Honestly, I don't think my experience is atypical either; I imagine most people picking one up don't have any linux experience at all. That is why I feel that Raspbian could be doing more to get the OS out of the way of users who are primarily interested in the GPIO.

    The saddest thing is probably that while you're wasting all this time arguing with us, you could be putting your case towards someone who could actually do something about it.

    https://forums.tomshardware.com/threads/raspberry-pi-ama-ask-your-questions-now.3492239/
  • bit_user
    Quote:
    All a person has to do is learn to use the tools provided by the OS; and, not to mention the man pages, the Internet is filled with documentation and HOW-TOs.

    But the OS (encompassing popular desktop environments, et al) is not a static, fixed thing. It's evolving, and there are lots of folks who are interested in making Linux more accessible. I think it's a worthy goal, so long as it doesn't "break" Linux for power users.

    Quote:
    After all, learning is just reading and remembering--easiest thing in the world to do--but nobody is going to hold your hand and spoon-feed you the knowledge. If you don't want to take the time to learn something...well, that's self-imposed exclusion, if you ask me.

    As such, I think the attitude that it's the user's own fault for not investing enough time and energy to climb the learning curve somewhat misses the above point. People have other things they want/need to do in life than invest a bunch of time learning a new thing, especially if the end goal is something relatively modest.

    I don't love Macs, but Steve Jobs repeatedly showed the world that computers don't have to be hard. First, with a custom-built OS designed to meet users on their terms, and then with an adaptation of BSD that has all the power and flexibility of any modern UNIX. I'm not saying that Linux should carbon-copy OS X, but there's a powerful lesson in that.
  • jejones3141
    Quote:
    Has there been any scenario where a Linux user had a command fail where they didn't immediately attempt the exact same thing again with a sudo in front? I'm really asking, linux users, have you ever thoughtfully considered if you made a mistake before you add on that sudo, or do you just immediately retry? For people who really do need that kind of protection from themselves, why make them retype the entire command every time instead of a single character "Are you sure Y/N"..


    Yes, sometimes I do. I try to make a habit of it.

    Quote:
    That's what always bothers with me linux, it deliberately uses the hardest and slowest ways of forcing users into its philosophy. Even when users agree with it they are still getting punished. Unless of course there actually is a way to use sudo through the GUI. It feels more like training users to instinctively ignore the 'safeguard', so why not cut out all the added steps?


    Yes, you can have windowing environments set up so that to run commands needing superuser privileges, it pop up a window asking for your password, and behind the scenes it is running sudo. On the command line, history is your friend. Hit up arrow, make sure you're at the start of the line, type sudo and a space, and hit enter, and poof! In a way you're right--"are you sure" prompts can condition one to thoughtlessly type "yes, yes, yes" followed by various expletives once you realize what you've done, but abandoning any and all safeguards is worse. It "makes things easier"--including destroying everything with no chance to consider what could happen.

    The relevant principle is the Principle of Least Privilege. Run with the least privilege needed to do what you are doing at the time--which means only running with superuser privilege when necessary.

    Quote:
    But why would you ever go back to running as a normal user, when that's the problem in the first place?


    Some may think themselves incapable of error. I don't, so I run as me and sudo only when necessary. Yes, I can wipe my own files, but to crash the system takes work and encourages me to think about what I'm doing.