Overclocking the Raspberry Pi 4

Features
By
last updated

You can overclock Raspberry Pi 4 up to 2.1 GHz.

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))

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 a good option, especially the Pimoroni Fan Shim. You should also consider 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.

Updating Your Firmware: At Your Own Risk

Depending on what firmware your Raspberry Pi 4 has, you'll be able to hit clock speeds that are higher than 2.1 GHz for the processor and 700 MHz for the GPU.  However, the original launch firmware for the Pi 4 could only reach 1.75 GHz on the CPU and 600 MHz on the GPU.  

If you want the latest and greatest overclocking ability on the Pi 4, you'll need to upgrade to the latest experimental firmware build, which could possibly have bugs. To update your firmware, enter these three commands in a terminal window.

sudo apt updatesudo apt dist-upgradesudo rpi-update

As of publication time, the highest speeds we had achieved were 2.147 GHz for the CPU and 750 MHz for the GPU, but newer firmware may let you push it even farther. Also, because not all processors are identical, your mileage may vary.

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=2arm_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. Each point here is worth about .025V.Th

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. If your Raspberry Pi 4 has the original launch firmware, 1.75 GHz is as fast as you can go. If you have the latest experimental firmware, you can try these values:

over_voltage=6arm_freq=2147

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.

After installing the latest experimental firmware on a different board, we ran Linpack (SP only) at stock speeds, 2 GHz and 2.147 GHz. In this run, the stock speed got a slightly lower score, but we saw a boost of 46 percent going to the highest possible clock.

When compressing video using the FFmpeg benchmark, we saw huge differences in performance. The stock speed took 49.3 seconds to complete this task while the 2.147 GHz clock managed to do it 37.3 seconds, an improvement of 24 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 gain of around 9 percent faster single- and 7 percent faster multi-threaded for the 1.75 GHz speed.

An image editing benchmark, built using the popular open-source GIMP software, benefits more from the boosted, 1.75 GHz 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 jump to 1.75 GHz. Moving up to 2.147 GHz increased it to 21.7, an improvement of 28 percent.

Not everything benefits from a 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 at 1.75 GHz. 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

If you have the latest experimental firmware, you can try boosting this number to 750. 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 while 750 MHz gives you a bit more.

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=6

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.

Image Credits: Tom's Hardware

Gareth Halfacree
19 Comments Comment from the forums
  • derekullo
    Mmm this rasberry pi smells delicious.

    Be careful not to burn the crust. :P
    Reply
  • 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.
    Reply
  • 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.
    Reply
  • bit_user
    Giroro said:
    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.
    Reply
  • k1664
    Giroro said:
    I'm an engineer,
    Giroro said:
    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.
    Reply
  • Giroro
    k1664 said:
    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:
    bit_user said:
    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?

    bit_user said:
    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.

    bit_user said:
    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).
    Reply
  • bit_user
    Giroro said:
    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.

    Giroro said:
    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.

    Giroro said:
    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.

    Giroro said:
    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.

    Giroro said:
    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.

    Giroro said:
    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).

    Giroro said:
    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?
    Reply
  • bit_user
    Giroro said:
    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.
    Reply
  • AllanGH
    Giroro said:
    ...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.

    Giroro said:
    ...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+Fx]; (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.

    Giroro said:
    ...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.

    Giroro said:
    ...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.pdfhttp://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.
    Reply
  • Giroro
    bit_user said:
    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.

    bit_user said:
    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.

    bit_user said:
    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.

    bit_user said:
    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.

    AllanGH said:
    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.

    AllanGH said:
    Helpful reading for those who need to learn about BASH:
    http://www.tldp.org/LDP/Bash-Beginners-Guide/Bash-Beginners-Guide.pdf
    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.
    Reply