Unix time is always the number of seconds since 00:00:00 Thursday, 1 January 1970 UTC time. Git records the committer's time zone, since the time would normally be converted back into a human readable form.
A lot of desktop applications do this. The Spotify client used to do it to enable play/pause controls from any webpage. Dropbox also definitely used the same method for single sign on, maybe still does, I don't use it anymore.
You’ve used past tense in all your examples. Is it still true? As Apple has moved more towards a system with GateKeeper where apps must operate in a sandbox, this behavior seems less acceptable in 2019. I don’t want apps having complete access to my home directory because they absolutely do not need it to function.
I like that when I remove an app installed via App Store on Mac, I know it’s actually gone. It seems like this was part of the thing that people couldn’t stand about Windows — spyware coming along for the ride that is not removed when you delete the main app.
Look, all that makes sense if users are giving informed consent to have an app install a web server. Users should be able to run whatever they want, but they should also know what an app is installing.
At least the Bluejeans people have this page. The Zoom people did the same thing (possibly worse), but it was undocumented.
I had a WiFi router that by default was set to filter out DNS responses with RFC1918 addresses. A surprising amount of stuff was broken until I figured that out.
>IMO there is a difference between “blockchain” and “blockchain technology”. The latter means taking parts of or inspiration from how blockchains are built.
>Even if the technology is not be specific to the blockchain originally, blockchain still helped bring these ideas into the minds of the masses and so I think it is fair to characterize some of these things as “blockchain technology” when that is how some people came to know of them.
What you just described here, when done to obtain money or publicity - is often referred to as "charlatanism".
It most certainly is not. You must have misunderstood what I meant.
If someone was introduced to a steamboat and they’d never seen a boat before (perhaps a far fetched example but stick with me here), and they made a rowboat and they said that they had built it on steamboat technology (because of the boat part) I think that would not be entirely unreasonable.
A charlatan on the other hand would be someone that sold you a steamboat and then gave you something that was not a steamboat, like for example a big rock or something.
A charlatan decieves people for fame or for money. Someone that sells something as “blockchain” when it’s not is a charlatan. Someone that was inspired to build something by blockchain and describes it as using “blockchain technology” should not deserve to be called a charlatan IMO.
It is still fair to point out that they are not actually using a blockchain, but calling them a charlatan is disingenuous because then what kinds of words should we use to describe the actual charlatans?
Not only is your argumentation and example really not solid -- the steamboat technology would in this case cover the steam engine, used in a large range of other sectors to solve the same and other problems. As such, you would not use the steam engine technology in anyway in the "derived invention".
If we go back to your original claim, you appear to be implying that a blockchain, to begin with, is a good solution of a immutable log -- it is not.
Depending on the scenario, there are in ALL cases that I have encountered at least, a better alternative solution, which is more efficient, already well researched, developed and tested. If you recon that you know an example where this is not the case, I would love to hear about it.
At the same time, you really do see people and companies who every single day, do use the blockchain as an excuse for a little extra gains in their stock valuation, like Maersk (the same Maersk who cannot even figure out how to divide their network into virtual lans, or have som network level malware protection).
> Not only is your argumentation and example really not solid -- the steamboat technology would in this case cover the steam engine, used in a large range of other sectors to solve the same and other problems. As such, you would not use the steam engine technology in anyway in the "derived invention".
But my point was that to someone who had never seen any boat at all everything that makes up the steamboat is steamboat technology.
>Sometimes it looks like people throw blockchain in a project not on technical merits but because they think the buzzword is a VC magnet.
That's because they do. A Blockchain without decentralization (and therefore no need for proof-of-work consensus) is functionally just an immutable, append-only object database - the same sort of data structure that any modern, distributed source code version control system (like Git) has always used, before "Blockchain" was even a thing.
It's sad how often this happens. I regularly talk with people in "blockchain startups" only find out that they're the sole operators of the network. Congrats guys, you just raised $30 mil to build a highly-clustered event sourcing database
Which is true, but what’s wrong with that? Perhaps there is a valuable approach to developing apps using a “blockchain” type approach, which enables trusted or non-trusted 3rd parties to more easily drop in on it than through a traditonal API.
Yeah, what raised a red flag when reading this project's description was that having a single kernel for all devices and no compatibility layer like libhybris is unfortunately an unrealistic goal in the world of ARM android devices.
An approach that is less likely to result in vaporware would be to maintain ports of Halium to older devices based on LineageOS kernels/drivers, with an optional Alpine Linux userspace.
Otherwise this project is little more than README.md Hacker News bait.
If there are enough helping hands, we could do this as a community.
The bootstrap program, pmbootstrap, is a working base component that makes development much easier (alone the automatically set up cross-compiling with distcc, ccache, armhf and native chroot), so it is definitely more than a README.md.
Also the title says, that the project is "aiming" - which does not say it has reached any of its goals yet. But at some point it needs to be announced to the community, so I might as well do that now, at a point, where other hackers could join in and parallelize development.
The biggest issue in trying to have a long running constantly updating OS on a Android phone is the device drivers.
Instead of trying to reverse engineer and make open source drivers, I think you should try a more generic approach something like a rump kernel or some other generic layer for each Linux kernel version which can simulate the interface needed for the particular kernel driver. That way you don't have to keep porting or reverse engineering device drivers.
Your approach of trying to make an open source driver is a losing one, it requires a lot of work and you can't reasonably keep up with it.
> Of course, the big if there is: Can you reach the critical mass of drivers without the project exhausting itself.
If that were the case, we wouldn't find ourselves in the current quagmire that we're in. Linux kernel already had a huge number of devices supporting it.
The truth is, there is nothing stopping device vendors from releasing a device driver for a specific version, maintaining it for an year or two and then abandoning it. The better approach would be to figure out a stable interface layer for kernel drivers so that you can simply plug and play the vendor supplied device driver.
Could you help me understand your reasoning behind not pairing up with or taking advantage of existing projects like Halium or LineageOS?
I'd love to run mainline Linux without any Android cruft on my old phones, but realise that this would take a lot of effort per each device. Each Android device is different, with its own kernel patches, proprietary modules and sometimes Android-specific userspace HALs. The Tegra in the Nexus 7 was designed to run non-Android Linux, there are native X11 drivers for that thing - that's not the case for devices like my current phone.
> Could you help me understand your reasoning behind not pairing up with or taking advantage of existing projects like Halium or LineageOS?
From the article:
> Of course I am not the only one, that came to this conclusion - especially in the last few weeks with the Halium project rising (greetings!). I am all-in for working together — sharing udev rules, merging Android kernels together, whatever makes sense!
> [...] postmarketOS does not fit the Halium model, as it avoids the Android build system entirely and does not run Android next to GNU/Linux.
> Thanks to Replicant, LineageOS, Halium. Together, we can make the vision of long-lasting, open source smartphone operating systems a reality!
So I see postmarketOS as part of the community. We have multiple projects, that want to provide a more open alternative to Android, on Android devices. This will only work out, if we work together and share, what we can.
postmarketOS differs from the other projects, that it tries to completely cut-off the Android parts. This will be harder for hardware compatibility, but then again, it does not depend on Google's upstream Android code (which does not get developed as a true community project, they only put out the source after they are done developing behind close curtains), and it uses less resources than running Android as second OS next to your regular GNU/Linux.
Regarding kernels and drivers, postmarketOS directly packages LineageOS kernels. Proprietary 3d acceleration will be avoided for now, some tests with "weston-smoke" and other demos showed, that it works fast enough without them. You won't be able to play 3d games, but that's not really in the scope of the project for now.
Very few mobile phone arm devices support device trees. Only Windows Mobile phones provided UEFI (with locked bootloaders). Most ARM devices just attach random shit to random pins and have totally non-upstreamable kernels.
I don't think he is talking specifically about Bitcoin, but "the blockchain of diamonds" type of startups that used to be hyped up on HN a year or so ago.
I'm going to take this opportunity to plug my favourite open source project - the Nix package manager[1].
It can work as a universal homebrew replacement (works on MacOS, Linux, WSL and can be easily ported to most BSD variants), comes with a huge collection of packages[2] and produces its own reproducible source builds. Like homebrew, it's a hybrid source and binary based package manager (if you haven't done anything to modify the build, it will likely be downloaded from a cache of pre-built binaries[3]). Unlike something like homebrew-cask, it will never download the pre-built .dmg file from the developer's website - with the obvious exception of proprietary software.
It can also work as a great AUR/ports replacement on Linux systems. Fedora doesn't provide FFmpeg or an up-to-date version of a package you need? No problem, just get it from Nix! All the advantages of a rolling release distro, without actually having to use one.
Due to its functional nature, it comes with a wealth of advantages over homebrew and other traditional package managers[4]. Once you get past the learning curve, creating your own packages or modifying existing ones is a breeze. It can create disposable development environments with dependencies of whatever project you're working on, without having to install them in your system or user profile! Check out the Nix manual[5] for more information.
It's so flexible that people have built a Linux distribution where your entire system configuration is a Nix derivation (package) - with atomic upgrades, rollbacks, reproducible configuration and much more! [6]
Essentially, all the benefits touted above apply here, but it is worth noting that Guix is a younger project. The author was originally a Nix dev, but found the DSL to be too awkward to use in practice, and opted to use Scheme through and through. Yes, Emacs bindings are available.
Also, Guix can now produce Dockerfiles, if that floats your boat:
The main thing that probably turns people off to Guix is that GuixSD specifically rejects any non-free software. While a noble goal, it leaves most people's hardware unusable.
The main allure to Nix/Guix is to be used for the internals of an OS. For example, NixOS is the most stable and maintainable system I have ever used, even though the documentation is absolute shit.
You don't need to fork the entire OS, though - just provide the relevant non-free packages on top of the regular OS.
Guix devs themselves have hinted that "adding impurity to a free OS is much easier than removing impurity from a non-free OS", so I suspect they may not be categorically opposed to the idea of non-free packages.
Do you use NixOS as a desktop OS? If so, what advantages do you find over something like Arch? I understand the repoducability from configuration files are often touted as a selling point, but I'm not reinstalling my OS regularly so I don't really see the advantage.
When I upgrade or (un)install a package, I get a completely clean fresh installed system. If upgrading my video driver broke my system, I can just pick the most recent version of my install from the bootloader. When I want to start writing code, I can use nix-shell to create an isolated environment with all the dependencies I need, and get to work, with one command.
At any moment, I know that my entire OS install is completely clean, devoid of any cruft, even if I have been installing and removing obscure software for months. I don't have a mess in /etc, in /usr/share, anywhere.
> I'm not reinstalling my OS regularly so I don't really see the advantage.
With NixOS, I'm never reinstalling my OS, because every update leaves me with a fresh new system, guaranteed.
Personally I run Arch on my desktops but NixOS on my servers. I mostly use Arch because of all the relatively uncommon stuff I occasionally use from the AUR (somehow I doubt STM32CubeMX or ESPtool will enter Nixpkgs any time soon), but I've occasionally ended up cursing that I couldn't do a Nix-style rollback when an update broke something important.
It's not Haskell, strictly speaking. There are some weird global state mutations in NixOS (I.e. the pkgs object) that aren't as intuitive as you'd like. Also, the novel file structure makes composing packages that aren't already built to do so quite difficult. Trying to get eclimd to work with emacs and eclipse was a giant pain.
I expect that your issue is more with the fact that there is a mega state object that contains almost everything - not that it is somehow global, which it isn't. You can't access it unless it is passed to you.
I breezed through your explanation with great interest and became more curious than ever to try Nix out at some point - I've heard tidbits about it over the past few months and found it to be a fascinating project.
Then I read some of the other comments in this subthread, about Nix being Haskell and Guix being Scheme, and how the internals don't conform to the principle of least surprise within their development domains - and became sad.
On the one hand, there are going to be teething problems, that's fine.
On the other hand, if I'm learning a new package manager, I ONLY want to learn package management. My brain gets really confused if I don't stay highly domain-specific when learning new things. So if you present me with "you need to learn B to grasp and work with A" you'll just get a duck trying repeatedly to jump up over the curb and failing. Looks hilarious, maybe, but very impractical.
I don't know Haskell or Scheme yet, which puts a great dampener on me using Nix for a bit.
As another practical example, emacs and vi do greatly interest me (particularly emacs' flexibility), but I'm not interested in having to learn Lisp or memorize a Nethack labyrinth of single-character keyboard commands (and the scopes for what works with what and where).
I suspect I might pick up emacs at some point after I've played with Lisp/Scheme/et al for a while, but that's not right now.
TL;DR: It's a strain for me to learn new things (basically do anything that requires focus and can't be done with passive autonomy) if my mental stack already has anything in it. AKA, I have a monumentally stupid variant of ADHD that gives me learning difficulties.
To be clear, Nix isn't haskell. It has its own domain-specific language. The documentation is a total mess, and months into using NixOS, I still don't really understand it.
That being said, NixOS is the best damn OS I have ever used. Period.
Installing NixOS is a total breeze. It's magical.
1. Boot live CD
2. Mount partitions
3. Write a simple configuration.nix
4. nixos-install
5. Boot a complete system, and log in with the user you defined in your configuration.nix (with a hashed password and everything).
nix-env lets you install packages in your home directory (without root).
nix-shell lets you create a special environment with specific packages, etc. and run a shell in that environment.
nixos-rebuild [switch test boot] (as root) creates a new system according to your modified configuration.nix. If you use switch, it (re)starts updated/new services all on its own. If you broke your system, just reboot, and pick the second most recent boot entry, and you will be back where you started.
TL;DR NixOS is well worth the effort. The benefits far far outweigh the headaches, and there is only room for improvement. You will start with a system that you cannot break!
While I agree with most of your comment and am writing this on my NixOS desktop, installing is a breeze only if you don't want to encrypt your root partition or don't want to use it on a macbook or something that mature OS'es usually do quite nicely out of the box.
I have my bookmarked set of gists to guide me through these things and it took me days to get it right the first time.
Also nixpkgs are a bit of a mess, you usually get a version of a package someone has bothered creating a PR for. This might be very old or bleeding edge. For specific versions you can be SoL. It is of course fairly easy to have your own .nix of the package and PR's are usually accepted quickly but the repo usually doesn't keep previous versions.
And then there is a whole world of pain regarding language specific packages. Python is especially painful for me.
It took me ages to find the page which hints at nix-shelling projects but this is a pita and requires a completely new workspace setup that is not compatible with people that don't use Nix.
Regardless I love NixOS, but to say this is perfect, not even close.
Please stop saying the documentation is "total mess" and "absolute shit" because this is far from the truth. There is comprehensive documentation available for Nix[1] and NixOS[2]. There is an online search for packages [3] and NixOS configuration options [4]. Sure the documentation will be incomplete in places but that doesn't make it "absolute shit", I have found it to be very helpful generally.
Comprehensive is not the same as user friendly, or well paced, or organized in a way that will assist new people learning.
I've seen plenty of projects that were exceptionally well documented. Every method and class had inline docstring documentation, every module has a separate module docstring block. 100% PEP 257 compliance was enforced as part of the CI tool chain... helpful but only after I was sufficiently knowledgeable about the way the project was being used to get any benefit from it. The the sheer volume of documentation meant that many people had written extremely terse explanations, often devoid of any of the contextual information that would significantly improve someone's understanding of how the code in question was be used.
Point is... The volume of documentation or the percentage of documented features, has no direct bearing on its usefulness to any particular user.
I was personally donating monthly to Nix foundation for past few years, the maximum amounts that don't trigger tax concerns, but finally pulled my funding after the team continued to bury their heads in sand about state of docs for newcomers.
The main site docs are incomplete and reference style. The Wiki which had some use cases also had a banner saying it was all deprecated.
So you get newcomers who can't orient themselves, and even advocates like thomastjeffery in this thread who love it but months in still think the docs are wildly unhelpful.
Interestingly, guys who understand it very well are no longer capable of seeing the problem. They forgot what it's like to have no idea how any of it works, so can't describe the happy path between ignorance and the lightbulb coming on -- or even see that path isn't lit.
For now, the only way to walk that path is either absolute focus on learning it w/ no time for a day job, or have your hand held by someone enlightened (which is expensive for your MVPs compared to fixing the docs).
Like I said, after months of using NixOS, I do not understand how to write a simple Nix expression.
Where is this explained?
I am speaking from experience when I say the documentation is "absolute shit". Most of the useful documentation I have read comes from the deprecated wiki.
When I first installed NixOS, I had to read the source code for simple things like defining a user or getting samba set up, and still had to rely on the deprecated outdated wiki.
Three current state of documentation for NixOS is spread between the manual, deprecated wiki, and the source code itself. The manual barely shows how to get a simple system working, but as soon as you reach an edge case - which Nix itself is fantastically suited to handle - you have to start digging.
In time, documentation for NixOS will be mature and usable, but right now it is severely lacking, moreso than any other aspect.
I guess not. I'm just still running Slackware, so I haven't needed to grapple with it just yet - and I'm holding out hoping to find that one other distribution that also doesn't use systemd so I can use that instead. :P
I've heard good things about Void Linux, I'll likely have a look at that at some point.
On the flip side of the coin, I've kind of accepted that everyone who uses Linux has to put up with systemd now, so I'll accept my fate eventually. It's just that I value constructive and positive communication, I don't like the systemd team's blatant arrogance, and I consider it a corporate abuse of power that nothing has been done to curb or deal with it. (I hope I never have to deal with Red Hat in a business setting. Feathers, sparks, fur... everything would fly, and it wouldn't be pretty.)
If you don't want to memorize single-character keyboard commands, why does vi greatly interest you? How do you plan to put it into use without those commands?
- people talk about how rapidly they can perform complex edits with few keystrokes, which is something I most definitely can't do with Geany (a Notepad++ clone that made me wish Notepad++ worked on Linux); and
- it's a standard utility that you can generally expect to be available in some form on literally every UNIX (especially server environments).
So, basically I'm being pragmatic. I'm at the point where I'm wondering about building my own text editor (something I've wondered about for several years, actually), but that immediately introduces a software-installation problem if I want to be able to bring that editor to other machines.
I have a small modicum of knowledge about how to get by in vi, but it's extremely barebones - exiting, copy/pasting (I think the wrong way, heh), not much else.
I definitely could learn significantly more, but I just have a massively hard time fielding the idea of "okay let's play with the text editor for a few hours". Sure, once I was actually doing it I'd probably find it fun, I just can't convince my brain's broken scheduler that it's not actually a waste of time :D
As an aside: I'm wondering about building my own editor because I want something that can jump around text similarly to the Canon Cat and which has syntax highlighting and autoformatting similar to QBasic/QuickBASIC - and I'm frankly petrified by the idea of adopting a text editor that uses Blink for rendering. Blink (aka Chromium) is like Flash meets Java for UI design nowadays, it's almost like crack, and I want to do everything I can to stay as far away as possible from it.
This is not because the systems using it are not well-designed or -built, but because I fundamentally disagree with the philosophy and idea of using a Web rendering engine for tasks like communication or text editing. HTML5/CSS/JS/WASM is the world's biggest Rube Goldberg "safely run arbitrary code from remote servers" in existence; it wreaks enough havoc on the Internet, I don't want it leaking into my desktop too.
My main complaint is the W3C: they produce specifications that are too narrowly scoped and at too frequent a rate for the associated implementations to be operationally cohesive. The code for each feature in isolation might be excellently architected and written, but as a whole the amount of memory and CPU churn undeniably associated with rendering engines is significantly higher than would be found in platform-native (or even cross-platform) solutions.
You can definitely argue "well that's how things are now, the Web will improve as time goes by"; I'd argue that no, things have always been a mess in the Internet community, and nowadays the driving forces are all companies with advertising and/or consumer-consumption interests. This in itself isn't necessarily wrong, but it means that the focus is "is it good enough? okay, ship it" and there's no conservative holding back until what gets released is of extremely high quality.
It looks like you can search the nix package list but not browse it? Based on clicking on the first few packages listed, most Nix packages are apparently for Linux. Is there some way to see which packages are available for Macs?
