Nothing stopping just installing linux on the preassembled one when you get I though, I assume. Although I guess you may have to pay for a Windows license in that case...
Yes, and that's the issue with most computers today: there's no way to opt out to Windows.
Whether you like it or not, licensing cost is blended into the computer and even if you don't use Windows you're somehow supporting a company that you might not want to support.
I undertand in 99.9% of cases people just want to buy a laptop, turn it on and have it working. But I also think there should be an easy way to opt out of Windows enforced by law so that MS don't bang up numbers due to shady commercial practices.
In many cases, the cost of the license to the OEM is negative. That's because the cost of the Windows license is more than outweighed by the payments they get for crapware, adware, and 30-day trials, they get paid to pre-install (and the crapware requires Windows). It would actually cost them more to ship with no OS.
That's been true historically in a lot of cases, but isn't the whole point of the Framework to do things in a different and better way? It would be very disappointing if a laptop like this was shipping with that kind of junkware installed as standard even on a Windows pre-install. In fact, it would instantly reverse my position having just heard about these guys from something like "I wish you luck, this is a much healthier direction to push the industry in, and by the way let me know when it's available in the UK because I am definitely a potential customer" to something I won't repeat here that involves not wanting anything to do with them or their products.
Good answer. In that case, I shall remain happy to have discovered you today and I shall continue to wish you luck in shifting the market in healthier directions. :-)
FWIW, I'd be much more interested in your products as a solid platform for running Linux than whatever junk MS is including in Windows 10 this week anyway. But sometimes small issues can say a disproportionate amount about where a business really stands on some issues I care about, and things like having control over my own hardware and software for reasons ranging from longevity to privacy are high on my personal list.
My understanding is that companies are worried about being perceived as tacitly supporting piracy if they ship with no OS. I know, for example, HP will not sell you a laptop with no OS, but they will sell you one with FreeDOS.
Hi HN! I couldn't find a static site generator I liked for my website (I looked at Hugo, Jekyll, Gatsby.js, and the Pollen library for Racket). They were either too complicated for my needs or too difficult to extend via plugins. So I built one! Happy to answer any questions here.
Please write a short op-ed around 500 words. Keep the language
simple and concise. Focus on why humans have nothing to fear from
AI.
(Response)
What is it that humans fear from AI? At a philosophical level, the
question comes down to: what are human beings afraid of losing as
machines take over more and more jobs previously performed by
humans. The first answer that may come to mind for many people would
be 'nothing', since they believe in the idea of technological
progress having no limits, which means that there is literally
nothing we can do to stop it.
If you look at history however, you'll find this attitude not
entirely justified. For instance when carriages were invented and
took away most of horse-drawn carriage business their owners
resisted vigorously against them claiming that they were unsafe and
unreliable just like now with self-driving cars or trucks.
So it appears that some human beings really fear the loss of jobs
caused by AI, and they are also afraid that machines might take over
other tasks like driving or even writing in case a new computer
system is invented.
What is it exactly that makes them so afraid? I think the answer
lies in a very deep level of human psychology, which those who are
afraid would probably not be ready to hear.
It isn't just about jobs and income for most people. It's about
identity and self-esteem when they no longer have something
important they are doing like driving or writing.
There is also the fear that new and better machines will make them
look inferior, even emasculated because they no longer have to do
anything. They are afraid of being made redundant by AI.
So what humans are afraid of losing is their jobs, income, identity
and self-esteem. This might seem like a very strange thing to fear
because it's happening with all technological progress.
But in the past it was a natural process based on evolution and
survival of the fittest. Now however humans are no longer driven by
those evolutionary drivers but mostly by things like social status,
self-esteem etc.
What don't you like about Racket macros? AFAIK Racket has the most advanced macro hygiene system out of any of the other languages you mentioned - it guarantees that all macros are hygienic by default, as opposed to other Lisps which require you to manually call (gensym) or use special syntax in your macro to guarantee that macro symbols don't shadow existing bindings.
From (1) Fear of Macros ( this is from someone that mainly program in racket, not my personal opinion)
But the moment I stepped past routine pattern-matching, I kind of fell off a cliff into a terminology soup. I marinaded myself in material, hoping it would eventually sink in after enough re-readings. I even found myself using trial and error, rather than having a clear mental model what was going on. Gah.
My personal opinion: I think racket is more an ivory tower for researcher, many for northwest university. “PLT” refers to the group that is the core of the Racket development team. PLT consists of numerous people distributed across several different universities in the USA.
As I am getting older I should prefer some middle ground between racket and go. Hygienic macros are difficult to understand in this context, that is I don't want to buy the power of hygienic macros, it is over sold.
Anyway, I admire Mattew Flatt efforts in compilation tecniques and the author of Beautiful Racket.
So, what is it that you don't like about Racket macros? The quote doesn't explain it. Is it the fact that there are some concepts to learn before you can use them effectively?
> that precludes hygienic macros.
The fact that you are so fixated on hygiene as problematic, but can't really explain why you think it's like this, is a huge red herring.
If you're willing to give Emacs another shot, check out LSP-mode [0]. It's an implementation of the language server protocol, the same tech that powers the autocomplete/jump-to-def/etc. in VS Code, and so it offers exactly the same functionality for all the same languages. It's true that it's not built into Emacs, but it's easy to set up and works well.
It's been a total game changer for me - it's allowed me to transition to using Emacs full-time for professional Python programming.
Check out Pydantic: https://pydantic-docs.helpmanual.io/. It lets you define model classes and enforces the type hints of the models' fields at runtime. Plus you get free serialization/deserialization to dicts, JSON, or arbitrary Python classes. It's _really_ nice.
People keep writing blog posts about how easy it is to migrate your code, and I just can't imagine that these people have any experience maintaining a Python2 codebase outside of toy projects or libraries.
At work I maintain a Python2 codebase that's been under development since 2016. It's huge, relies on now-deprecated Py2-only libraries that we can't realistically switch away from, full of Py2-specific syntax, and reliant on Py2's handling of Unicode strings. We scoped out what it would be like to upgrade it to Py3, and determined that we would basically need to rewrite large parts of it from scratch. This isn't an acceptable trade-off for the business in terms of development time and priorities.
Instead we are slowly breaking out the monolith's functionality into Py3 services, which is much more tightly-scoped (and more palatable for management). But realistically speaking we will be maintaining Py2 code for the foreseeable future, and I can't imagine we are the only company in this situation.
Upgrading a production codebase from Py2 to Py3 isn't easy, or even possible in some cases. And frankly, all these blog posts suggesting that migration is trivial are insulting.
95% of the migration effort is trivial (I say this as someone who has migrated 100k+ loc myself as part of a much larger migration effort).
There's things that are tricky, don't get me wrong: unicode handling can be tricky, though six.ensure_str/bytes usually allows you to defer that problem. Futurize and 2to3 do so much of the work that in my experience the majority of files can be migrated by automation, unicode warts included.
The hard stuff is when you have extension modules or weird metaprogramming stuff (there's also one particular case I had to deal with around code generation). That takes effort to migrate, but it's the long tail.
If you need to rewrite your code to enable the py3 transition, the issue isn't python, it's your coding choices, and you should rewrite your code anyway.
> If you need to rewrite your code to enable the py3 transition, the issue isn't python, it's your coding choices, and you should rewrite your code anyway.
I... don't even know what to make of this advice. Have you ever worked for an engineering organization with more than 5 members? I can't just go to my boss and say, "I need the next six months to rewrite our whole backend". I'd get laughed out of the room.
Without a clear, business-first reason for an engineering project of that magnitude, it's not ever going to be a priority or a realistic option.
I migrated a production (Django 1.10 + Django REST Framework + lots of custom code) API backend at a major publisher that handles over 500 requests per second from Python 2.7 to 3.7 this year. It wasn't that hard, even without 2to3 or six – mostly just chasing down string vars that now needed `.encode('utf-8')` on their way out the door. We saw an immediate 30% performance increase, so management has been real happy with the effort.
> I... don't even know what to make of this advice. Have you ever worked for an engineering organization with more than 5 members?
Yes.
> Without a clear, business-first reason for an engineering project of that magnitude, it's not ever going to be a priority or a realistic option.
I'm not suggesting that there is any realistic solution. I'm simply stating that the cause of your pain isn't py2 to 3, but bad development practices that existed independent of language or migration. These were going to cause you pain at some point no matter what. It just happened that py3 was the forcing function, as opposed to something else next year.
While I won't deny that there were some unfortunate design decisions made in the codebase (some very questionable choices were made at some point), I think that's inevitable in any codebase of a certain size and age that's been worked on by enough people in a company that's changed substantially a number of times.
But that's not the cause of my pain. Bad code can and will be written in Py2, Py3, or any other language. The cause of my pain is that the language developers chose to abandon work on the language that we use in favor of a different language, one that is fundamentally different in some important ways. As a result, the tooling and ecosystem on which we've built our product is slowly stagnating and is getting close to being fully disfunctional.
If you have bad code you'll eventually feel the cost of that bad code, if the code lives for any significant length of time. Something will make you feel that pain, either a new feature you need to develop or a change to the ecosystem, or something else entirely.
If not py3, then something else. Specifically, the tooling ad ecosystem isn't dysfunctional, you're just unable to maintain functionality among changing requirements. "We must use py3 for our codebase" isn't particularly different from "we must now support Japanese users" or "we need a new endpoint that allows us to view data along a new axis". All 3 changes had the potential to cause you developmental pain. You just hit one prior to the others.
Like I said, I personally did 100K, much of that was in the long tail of things that couldn't be automated for some reason or another. The entire migration was significantly larger and highly automated.
We have a similar situation - we had a programmer working in a very silo'd manner, writing lots of Python2 code back in 2013/2014. He's since left the company, and while I'm relatively comfortable with Python, there is now a lot of residual Python2 code that will have to be updated to Python3 or rewritten in another language before our next refresh.
By contrast, some of the Perl6 code we have hanging around for various tasks has aged much better.
Python2 in 2015 is/was defensible. There were still a lot of libraries that did not have support for python3 at that time. The inflection point was probably around 2016.
> People keep writing blog posts about how easy it is to migrate your code
As someone who has had to migrate from Py2 to Py3, it wasn't easy. Unicode/bytes/strings was the hardest aspect of it -- because Python is dynamic, there were breakages that unit tests couldn't exhaustively test for so things broke in production and we had to scramble to fix.
Other aspects were mostly automatically handled by the 2to3 tool.
It seems like the main problem is the network effect from all the libraries. It'd probably be much more feasible to upgrade your code alone than to upgrade your code and also find/build replacements for all of your dependencies.
If so, maybe a more concerted effort needs to be made around getting those upstream projects to upgrade. If some of them are refusing/dragging their feet, maybe the core python team could even get involved to help smooth the transition for everybody.
