Typing this on 12th gen running Fedora, and I have none of the issues you describe. I've been daily driving this laptop for 2 years, and my only complaint is the mediocre battery life (I get 5-6 hours with mixed use and around 50% display brightness).
I did switch from the glossy to matte display, which was a massive improvement for use on the go.
I have a similar usage pattern where there might be days at a time where I don't boot up my personal laptop. With an 11th Gen and Fedora I set it up with a swap partition and force it to hibernate after 30 minutes. So far it's worked well.
It can take 10-20 seconds to boot up but battery drain while not is use has dropped to maybe 2% for any extended periods of non-use. As an 11th gen user, it exacerbates the CMOS problem I mentioned earlier but that hopefully shouldn't be an issue with the 12th gen mainboards.
To be perfectly honest, I don't really know how much battery I would lose - the laptop is rarely untouched for more than a day or so and in the rare situations when it has been, it has been either completely powered off or left plugged in. I don't know if it's ever been in a situation where it was left in a sleep-state for multiple days.
Fun project. You might be interested in belt presses - they can be hooked directly to the grinder reducing the time (and labor) of moving the pulp to the press. They also allow the whole process to run continuously.
These are neat! I've been vaguely aware of them, but never looked into them too much. It's hard to find DIY plans online for that sort of thing, and I'm not sure I'd be able design my own from scratch well enough to be worthwhile.
In a similar vein, swap out the grinder for a shredder/wood chipper-type model. You will no longer have to cut the apples open, and you can fill it by the bucket rather than one-by-one. Much higher throughput.
To clarify, with the grinder I built described in the post, I did not have to cut open apples by hand any longer. It could shred apples as quickly as apples could be put on the ramp.
Just finished looking into these more. While they seem really neat, even if I home-built one it would be way out of my price range. Just the filter belts alone would cost more than this entire project did.
Funny thing is this has actually motivated me to move away from using rmarkdown. To the point that I went "backwards" and wrote several reports and an academic paper in Sweave after using rmarkdown for years. My primary motivation was that I needed to know the documents could be built by any R session, not just from within RStudio. I didn't want to be in a situation where my "reproducible" document relied on a specific IDE to build correctly.
We generally treat “working in RStudio but not elsewhere” as serious bugs, especially in our open source R packages. Not only because we don’t want to artificially limit usage of other interactive environments, but because a lot of what people do with R is run their code in non-interactive settings like CI/CD pipelines or ETL jobs.
(Actually, an R Markdown compilation is a particularly good example of something people often do from Travis or GitHub Actions)
I actually use Emacs to author R Markdown and the exporting works pretty flawlessly.
Before anyone asks, I use Org Mode. I just don't feel like pushing that format on my co-workers. If it's for me only, I use Org. If it's for a collaboration or export into a report, it goes into an R Markdown file.
Curious: how does Org-Mode compare with RMarkdown's use case? I'm only tangentially familiar with both. I've had the hardest time getting into Emacs (Doom-Emacs), and while Org-Mode seems great, the benefits seem to come entirely from Emacs, not the syntax.
I used markdown + pandoc to write my PhD thesis, but was forced to resort to latex for any formatting that was even slightly complicated (ie, multifigure plots, tables, etc).
I have created portable (for Windows) versions of R and R-Studio that work fine for the most part. However I was unable to make Bookdown work on them.
An official portable version of R-Studio: one that lives off a folder in the computer, and can be moved to a new PC in a pinch with all settings and plugins intact, and works with all official packages... would be very sweet. (Reason: upgrading from one PC to a newer one is a pain if one has to install application software from scratch. Copying over the "portableApps" folder is so much easier.
I'm all for finding alternatives to RStudio's dominance in the R space. No doubt they do some excellent things, but I also have a vague uneasiness at the cultishness surrounding some of their products. It sometimes feels like if you're not using the 'tidyverse', you're viewed as doing it wrong.
Anyway, this feeling set me off on an exploration of alternative tools and packages. Instead of rmarkdown I'm now exploring the pander[1] package, which seems to do most of what I'm looking for, perhaps only a little limited in output formats.
Edit: The Pandoc.brew examples might be most interesting from a direct alternative to rmarkdown for document creation context.[2]
For me part of the cultish ness is justified because I have to teach about 100 non programmers to use R and rmd every year. Tidyverse solves the big problem that R used to have was that there were hundreds of ways to do things, none of the functions had consistent naming or calling signatures and it was hard to Google sensible answers. Tidyvers is fast, consistent and has good docs. Pipes discourage lots of mutable state which is a major cause of errors in non programmers code. I think if you are going to be sharing your code with other researchers and are not using tidyverse then These days I think you basically are doing it wrong.
Hmmm... I've always found tideverse syntax inelegant. Data.table syntax does more with fewer different words. But it can get a bit convoluted. Any ways: there are different ways to solveing problems and writing code. Should we not encourage this? Otherwise it's just cargo cult again and again.
To a point. I’m actually a data table user too, but it’s actually a pain at the moment (and a good example of why tidyverse quality matters) because they broke the integration with reshape and made me rewrite a bunch of guides a while ago.
I don’t like to encourage cargo cutting, but to some extent it’s needed as a beginner. Heck, we’re all still cargo culting to some degree unless you also understand the machine code.
I teach a graduate course on R every year. One of my points on the Tidyverse is that it does an excellent job of providing clean and sound extensions to core language functionality. I emphasize how thoughtfully designed it is. It is a refreshing change from other languages, which feel more like a collection of random parts.
To be honest, I can feel the "cultishness" you mentioned, but I'm curious if you also feel that for R Markdown products (which are mostly irrelevant to Tidyverse). If you do, I'd love to try my best to fix that, because that's something that I personally don't like. I want to make it clear that if you don't use R Markdown, you are definitely not doing anything wrong, e.g., LaTeX and HTML are totally legitimate and supported:
I also learnt R before tidyverse was a thing (2007), and eventually abandoned it for Python & Pandas a year before tidyverse came out. I sorely missed ggplot, but I couldn't justify the ugliness of R to make up for it. Now when I look at R code, it's almost always tidyverse, and makes little sense to me.
I'm one of the main developers of R Markdown. As @jcheng said, it is definitely not our intention to lock you in RStudio for any of our R packages. You probably can't imagine how hard I have been trying to avoid relying on RStudio specifically for certain features. There are decisions that I can definitely make in favor of the RStudio IDE, but usually I don't do that, and hope things also work well with other editors. Pretty much everything you do in the RStudio IDE for R Markdown documents or projects can be done in command line. It's not possible that a document is no longer reproducible just because you stop using RStudio.
Which parts don't work outside of R Studio for you? Is it something recent? I usually create my single-page and bookdown documents as one step in a separate R script, and haven't found any problems beyond the rmarkdown package's poor documentation (I really wish the R Studio developers would write in-package documentation with as much care as with their online documentation).
If I recall correctly, I had issues primarily with more complicated documents, and mostly due to some RStudio "project" and file path configuration issues - I would have to look to see what the specific issues were. Simple, one-file .Rmd docs are typically fine either way.
It's pretty easy to compile the documents; it's all just R functions (rmarkdown is a wrapper around knitr and pandoc). I've been writing Rmarkdown docs for many years in Emacs without hiccups (or without hiccups from rmarkdown::render, anyway).
I've been using Rmarkdown and knitr for a long while, and have watched its evolution over the years (roughly 8 years now). As someone who does not use RStudio, it's become a bit of a pain for me to use. The authors seem to expect it is being used from RStudio, and using it in a different environment has become a bit fragile.
It's also a bit telling that this "definitive guide" does not include any troubleshooting/debugging sections - the expectation seems to be that it "just works" so long as you use it in RStudio, but otherwise you are on your own.
Not sure that I am aware of many other R packages with this mentality, but I am personally not a fan.
I haven't used it for a few years, but I have previously set up some purely command line tooling for this (autogenerated verification reports) which worked well. Is this getting harder to do?
Some functionality has been tied to RStudio's concept of a "project" (https://support.rstudio.com/hc/en-us/articles/200526207-Usin...). I have had several documents authored by others which would not build on my system without some intervention due to this.
While I agree with many of the negative comments here about issues with how this is implemented, the tone of some comments is... not great. To the point that I would be reluctant to share work I do in R on Hacker News, which is not helping anyone.
No kidding. Seems like an elegant solution to a potential problem to me. I've only used R at the "poke stick at numbers" level, but this would have been a useful addition to that trivial use.
My first thought was "I hope I never encounter code that uses this." It's interesting as a proof of concept, but it makes your R code difficult to understand to 99.9% of R programmers. In my opinion, that is a pretty high cost for what I would consider mostly syntactic sugar.
That said, a lot of the use-case of R is one-off scripts, run locally on a machine by an analyst, as part of preparing a written report for non-technical stakeholders. So the code readability isn't as important.
This is both a strength and weakness of R in general. The R community has many different ways to accomplish the same goals. Production systems decline to use R in large part because of the code maintenance burden across a team, versus Python's "one right way" approach.
Every time I think code readability isn't important, I am inevitably proven wrong. Either I need to go back months later and need to figure out what I did, or I end up sharing with others. Even those one-off, "never going to touch this again" scripts.
I found that the "one right way" python's mantra fall apart when it comes to pandas and numpy. Those libraries must be seen as DSL on top of the language IMHO.
Fallow fields are essential to maintaining soil health, a successful practice going back 10k years. Additionally, some of the "barren" fields are actually being used to alternate crop - it is a technique to grow crops with limited natural water. Modern best-practices avoid a lot of erosion by using no-till or low-till systems.
I read up and watched some videos in re: "syntropic agriculture" last night. Ernst Götsch's farm produces crops all year w/o any inputs and with continuous improvement of the soil quality.
So, in my grad program in ag, we had a Bay-area ML startup come in to give a seminar on how they were revolutionizing agriculture. The presented their findings on how to increase yields (which they claimed could only be understood from their algorithm).
The problem they were diving into was well understood, and has been researched to death for the last 100+ years. And they had the relationship backwards, not understanding their "input" to increase yields was actually a response to low yields. They were the opposite of helpful, but rather a waste of our time.
As with anything, it helps to know the current state of knowledge before you jump into contribute. An understanding of math doesn't get you there.
Hi - coming from a PhD in agriculture (focus on sustainable ag), graduate level courses are going to be tough to jump into unless you have a strong background in ecology. Most of my grad-level courses assumed years of training in e.g. genetics, soil science and chemistry, plant physiology, ecology, weed science, entomology, etc. Agriculture is a very broad life science field.
That said, if you want a quick primer, "Crop ecology: productivity and management in agricultural systems" is a good primer on most of the basic ecological systems in agriculture. I've read it cover to cover many times.
However, you don't need a grad-level education to farm (believe me, I have been reminded this endlessly) - this is more for people doing research. For applied/actionable specifics for cold climates, your best friend is going to be local crop-extension services (in the US, most land-grants run an extension service). They will have tested techniques for your area and will be able to point you to good resources for farmers, not people researching agriculture.
One last thing - to be a successful farmer has very little to do with growing crops. Take business classes - the rest is relatively easy to figure out.
You probably can grow them (you can "grow" a potato in a cup of water on your counter), but probably not profitably. Potatoes have a fairly low commodity price relative to their light and space demands. Additionally, they store and transport really well.
I did switch from the glossy to matte display, which was a massive improvement for use on the go.