Do you have an example or generally what kind of searches you are referring to? My experience with ddg has been "good enough" at least. The few times I don't find anything usable on ddg I ususally end up not finding anything on Google either
Not the poster, but here is an example. Elsewhere in this thread I posted a fact that I knew, but wanted to double check. It was about the LexisNexis news database containing 35k sources.
Here are the queries for "lexis news 35000" on Google and DDG:
You have trained Google to recognise Lexis as an alias for LexisNexis. DDG does not offer that, so one has to spell it out explicitly. You have to decide whether it's acceptable for you to change habits back to the common ground for Web searching.
The value provided by magic intent recognition (as opposed to traditional searching for keywords) differs from person to person. On the whole, it's likely for the better and that's why that feature was implemented at Google, but I have also read countless complaints about it on HN because situationally it pollutes results and can't be turned off.
You have trained Google to recognise Lexis as an alias for LexisNexis.
I disagree completely. Google knows Lexis is an alias for LexisNexis, but I did not train it from an individual level filter bubble perspective.
Look at the below results. They are sourced from Google but proxied so that Google doesn't get any information on the end user. The firsts result should be one that provides the relevant article I was initially looking for. [0]
Just one final point. Half the results on the DDG page for initial "Lexis" search I ran are for the car company "Lexus". So let's not pretend that DDG is respecting user search queries.
>Nexis is an online service for your strategic news and business research. Search for content from 35,000 publications. Conduct accurate searches of the 35,000 international sources in the Nexis online service. Make informed business decisions after getting the latest news and market reports.
this was the 8th result for me in DDG, with no filters or customisation or anything
this was the 8th result for me in DDG, with no filters or customisation or anything
So that link was 9th for me in DDG, but that exactly proves the point.
Google returned a relevant result in the first position. In addition, look at the result snippet from DDG:
The world is moving fast - Nexis news alerts help you keep up by delivering current news and information related to companies, trends, and events that matter to you. Set a Nexis alert related to a particular topic and get updates online or via email.
I wouldn't know that page had the information I was looking for unless I visited the page and reviewed the content. That's a lot of effort, when Google has the information in the top result and the snippet clearly indicates it is on the page.
(Edit: I also just looked at the content on that page, and it doesn't provide the information I was looking for. It provides the number of sources across all Nexis' searches. I was only looking for information on the news library.)
Also, half of the Lexis results on the DDG SERP are about Lexus the car.
Like I said, I like the mission of DDG, but in this and many other examples the organic SERP relevance is worse for multiple reasons.
I will try to document it for the next time this comes up.
I notice that Google is better at naturally knowing what I am looking for, and that DDG will show dodgy websites more often.
If I am searching for a PDF or a user manual, DDG will give me a lot of sites that are almost certainly malware laced (pdf-manuals.xyz) or something vs. what I get from Google.
Their maturity filter doesn't work as well, either.
That has been one reason why I prefer DDG to google since day 1; I can tell it to give me stuff from my region, or just international. Considering I use the internet in english 98% of the time but occasionally need something specific to Germany, that's very useful indeed :D
Coming from the world of tiling window managers on linux, I do not use a touchpad at all. On the Macbook I have to use it occasionally, but I still stay on the keyboard as much as possible.
So having to remap ESC to Capslock and often hitting the wrong arrow key is a much too big drawback to a bigger touchpad
Maybe according to OPs perception, the reasons destroying the middle class and upward mobility are a combination of: competition pressure centered around places with strong "second place" (Job) opportunities, decades of civic mal-planning, treating symptoms (for some) rather than root causes (for all) and regressive tax/compensation structures
But I am not sure what that actually means. And I am not a native speaker.
Yes, and the Ptolemaic Kingdom was a Greek kingdom founded by Ptolemy I Soter, a companion and historian of Alexander the Great. He started the kingdom after the death of Alexander.
That is how my setup works in the terminal. MPD (music player daemon) runs from the start in the background and I can start ncmpcpp in the terminal to choose a album/playlist and then I can close it again or leave it on a different workspace.
Play Pause etc. just work without the terminal. The biggest advantage in comparison most graphical players for me is that there is no startup time. If I want to play a song I can do so immediately and even without leaving the terminal I am currently working in.
There are different issues with OSX though, that colleagues of mine had, that never occur with Linux. E.g. the chore of somehow managing different software versions such as the outdated default one and a second one installed with homebrew. Almost all my colleagues struggled with setting up python 2 und 3 correctly at some point, whereas this just worked for me on Linux.
Some struggled with font rendering between a 1080p monitor and their Retina displays as well.
Languages and platforms generally are best supported on linux. Clojure, haskell, python, anything except the platform provided by the Apple/Microsoft is easier to configure on linux.
C++ ecosystem sucks a lot when you have to build 5 libraries using 5 different building systems. Linux package managers do that for you.
Yet VC++ offers much better tooling, including pre-compiled headers, incremental compilation and linking, experimental support for modules, C++ friendly OS APIs, and a package manager actually written in C++.
And a project config system that will break everything at the slightest provocation! Seriously, setting up even moderately complicated multi-project solutions usually results in days lost to figuring out why x library isn't linking with y project. The editor is great, the build system is somehow worse than make/cmake.
> However, the Python ecosystem isn't doing anyone any favors here.
Apple isn't, either. They ship a version of Python by default that is woefully out of date and conflicts with any other Python that you install, and what's more, some of their tools (notably, LLDB) freak out if you have a newer Python on your $PATH.
I have struggled occasionally with the various Linux package managers not being able to resolve Python library conflicts/dependency conflicts. Like, really, things where you wonder how possibly could there be a conflict, such as scipy not being able to update because matplotlib ver whatever being needed by some other lib that interoperates with scipy but itself is updatable something something something.
I'm still not sure I know the best way to install Python packages. It seems someone has something bad to say about any given method (pkg mgr, pip, venv, etc).
I just use nix on OS X, better package manager than most linux distros have. I have my own copies of py2/3 and the system one, not a huge deal to be honest (outside of the pain of linux side nixos updates breaking derivations for macOS, but thats generally not a fault of the os).
Last time I tried Nix I eventually got the Nix environment working, but ran into MacOS-specific issues trying to install relatively common development-related packages like Ruby and PostgreSQL.
It's waaaay better than it used to be. A couple of years ago there were a lot of impurities which would cause everything to break whenever macOS was updated. But these days it just uses libSystem from macOS and the rest is managed by nixpkgs.
This is at least as bad a problem on Linux — I would argue worse since I've seen people break the system tools written in Python — and it's mostly due to Python being old enough to be both widespread and to have accumulated tons of easily-googled bad advice. The people who have problems with this almost always also have tons of similar problems with everything else because they've avoided learning enough system administration to work cleanly or troubleshoot problems effectively, and that's unfortunately cross-platform — they'll also do things like copy DLLs into Windows system folders, get annoyed that rpm/dpkg won't let them install the wrong version of an important library, etc.
The main thing is understanding that the system python installation should be left alone and you should install each app/project in a separate virtualenv / venv so their versions of Python & installed packages are isolated from the system and each other. This also tends to get rid of about 99% of the times where someone try "sudo <previous command>" before reading the error message.
These days I tend to recommend using https://pipenv.readthedocs.io/ or https://poetry.eustace.io/ which will automate creation of those virtual environments and provide a nice interface for managing versioned package installs (i.e. `pipenv install foobar` will record the exact version you installed, including SHA-256 hashes, for repeatable installs).
If you're in the Red Hat world, note also that they're making some big (and I think welcome) changes to isolate the Python they use from the version developers use, which will also allow tracking newer versions faster:
I was looking at venv, but I guess not fully looking through into deployment. Do you know if venv works with setup.py bdist_rpm or is there nothing standard linking the two concepts?
To be blunt, Apple would be better served removing any and all of the outdated packages, not even bothering to include certain packages at all, and just telling people to use one of the several community supported package managers. The GNU packages especially come to mind since they are all out of date anyway.
If there’s no requirement from some OS feature to have a particular package preinstalled, I would rather not even have it in the base system if I’m just going to have to replace it with an updated (and updateable) version.
I might be unlucky but Linux had been a nightmare on the few laptops I've tried it on. It is not that I have not tried. I did. Some of the problems I had: Very slow UI, not recognizing my Wifi Card, Chrome stopping support for CentOS, Problems with the Graphic Card and multiple monitors, problems with most printers I try, problem with my Bluetooth mouse...
Linux and the multiple variants have been horrible. Also, you commented about Python 2-3, I agree I had issues with OS X. But you are ignoring the fact that installing software on Linux is still a mess of resolving all the dependencies and the package manager. Where in OS X, it is just a file move to App.
Nowadays, I run dev code on a Linux docker container. I do pretty much anything else on OS X.
Your experience running Linux on a laptop is highly dependent on how well it supports the hardware that happens to be in your device. If you're able to research the driver support ahead of time, you may find that Linux runs flawlessly on the laptop you bought. If you install Linux on a random laptop, then getting wifi, audio, etc working can be hit or miss, depending on the drivers.
As far as installing apps, I guess it depends on what you're trying to install. In my experience installing apps is easier on Linux than on any proprietary OS, so long as you're installing open source applications and working within the package manager and keeping your system up to date. If you want to run proprietary software on your open source OS, then yeah it's more difficult since Linux distributions aren't really designed for it.
> Your experience running Linux on a laptop is highly dependent on how well it supports the hardware that happens to be in your device.
My second mainline Linux install was a copy of RedHat on a laptop.
Mind you, this was RedHat 5.1 on an old 486 laptop with 8 meg of RAM, PCMCIA, etc. Sometime in 1995 or 96, I forget.
Several re-compiles later, I had that entire system working - all drivers for all the hardware, including the built-in modem (plus sound and PCMCIA ethernet).
I had an Asus laptop that would only pickup wifi if I hibernated it first. I have a Dell touchscreen model that took a full day to get the touchpad to work at all as Ubuntu kept defaulting to the screen. Too afraid to do a fresh install of the current (or any other) distro because I can't remember how I fixed the touchpad issue.
It sounds like you were really unlucky. The last time I struggled with any of the issues mentioned by you is at least 4 or 5 years in the past.
> But you are ignoring the fact that installing software on Linux is still a mess of resolving all the dependencies and the package manager. Where in OS X, it is just a file move to App.
This is also highly dependent on specific experiences. I haven't had any issues with conflicting dependencies on Arch linux in the past few years. And personally I appreciate a system package manager for all software instead of having to download applications and doing drag and drop for installation
Sounds like you just got lucky with the versions you happened to need vs what the system versions were on your version/distro of Linux. It's not like Linux has a built-in solution to the problem, you can definitely still have issues with conflicting versions.
BTW, on either platform your best bet IMO is installing all your scripting languages within some kind of version manager. I like pyenv, rbenv, and nodenv since they work exactly the same way between the three languages.
I have a feeling that Apple doesn't want their users to install that kind of development environments, other runtimes, etc. to their MacOS installations. Time Machine also sometimes doesn't Backup these installations correctly.
Similarly, TeX installation is hard and it's forcefully shoehorned on the installation, and you can't do anything better in the current situation.
My solution is to run a Linux VM for these situations. For programming and server-like purposes, a headless minimal installation is fine. For TeX authoring, an XFCE installation is very handy and not impacting battery life in a visible way.
It was. When I got my first Mac in 2008, it was very straightforward. When Apple started to tighten OSX security they stumbled a little IIRC (I cannot find the old warnings and notes on the page). Also, around the same time, OSX installer changed, and OS upgrades started to take longer since TeX installation had so many files.
When they were working on these problems, I was in the middle of my Ph.D., and I needed a stable TeX installation, fast. I installed a Linux VM, all my woes went away, and that method just stuck.
I just checked the MacTeX page now, and it looks like they solved the problems I mentioned above, but currently I'm too lazy and need that TeX installation keep working, so I'll not retry it now.
To be fair, that may be a python problem, as I've also had issues with 2 & 3 on a Linux machine as well. At this point, unless I can avoid it I just use a VM for any python 2 work.
OSX comes with some software such as git and python2 preinstalled. However they do not usually keep that software up to date and there is no way for you to change that, which means that community package managers need to be used to install more up to date software versions in parallel to the system ones
This is a pain point. I use pyenv+pyenv-virtualenv+pyenv-implicit to keep me sane on MacOS (and everywhere else honestly, system python is for the system.)
This was my main complaint with OSX until I tried nix. When I ditched homebrew and reinstalled the same packages with nix, I don't think a single one had problems. The CLI has some stupid pitfalls though..
1. brew install pyenv
2. pyenv install 2.7.x
3. pyenv install 3.x
4. cd work; pyenv local 3.7.x (by default, all projects under "work" will use 3.x)
5. cd work/legacy; pyenv local 2.7.x (but this one will be on 2.x)
then for each project, I'll create a separate virtual environment.
For various reasons, I have about 6 separate python versions and a dozen or so mini projects all working flawlessly as separate virtual environments created under separate versions managed by pyenv, and I always have the latest pyenv thanks to brew.
