-
Thanks! Having a place to sleep during a hackathon is very important to me and this makes it happen :)
-
-
While the tool seems like a handy one, it does sadden me that in this day and age the installation method is
curl | sh.-
Agree 100%. I don’t know how that dire mechanism of installation became “a thing”. FFS, it’s everywhere and it annoys the hell out of me. I guess people can argue that it’s the same as
make installas root (which I also dislike), but at least we’ve moved on in that realm, to binary package managers. -
What would you prefer?
-
A traditional tarball for a start? And for those that use it, the ability to install it using their package manager of choice (I see Homebrew support is on the way).
-
A traditional tarball for a start?
Are you just saying you prefer to untar > ./configure > make > make install route? I don’t really understand the benefit of a “traditional tarball” other than if it had an MD5 to go with it to verify package contents.
And for those that use it, the ability to install it using their package manager of choice (I see Homebrew support is on the way).
Yeah, I definitely prefer a package manager to
curl # | sh
-
-
-
-
-
Learning and reading about new technology and futurism. Reading science fiction and non-fiction. Hiking. Guitar and other music. Figuring how to increase my value as a human.
-
-
Shameless plug, but M:Tier has released binpatches already:
-
Perhaps a bit late to the party, but Wallabag is quite nice too. While there’s a hosted version available, you can host it yourself too for those who rather keep control of their data. They also offer extensions for Chrome/Firefox and apps for Android, iOS and Windows Phone.
-
Hmm. I need to check out efifb. VESA hasn’t been bad, but the grass is always greener…
-
-
Hmm, does this 404 for anyone else?
-
Yes. http://blog.jasper.la/openbsd-uefi-bootloader-howto/ works for me.
-
-
-
Clicking the post’s URL
http://blog… returns a 301 tohttps://ghost.jasper.la/openbsd-uefi-bootloader-howto/which doesn’t resolve. If I visithttps://blog… it works.
-
-
-
-
-
@tedu: Is this like most ARM boards where u-boot and all the configuration is stored on the flash’s fat partition rather than firmware? If so, given the lack of removable media, any idea what the recovery path would be if one were to dd /dev/zero over sd0c? I’m assuming it wouldn’t be completely bricked.
-
-
Depends on what you mean by “bricked”. I’ve bricked an ERL two years ago but that was damage from (un)plugging the power cable too often (before I finally able to let OpenBSD reboot the machine). That had little to do with software-wise bricking and I haven’t been able to brick the replacement unit in a long time with all kinds of uboot abuse…
-
-
To answer my own question, a little research indicates that the internal flash is a removable USB drive, and should fit most low-profile USB flash drives for repair or upgrade.
-
There is only one internal port […]. The internal flash is not supported and it’s not all that much anyway.
https://marc.info/?l=openbsd-misc&m=143991263125175&w=2
There’s an MSDOS partition on the USB disk, maybe it’s the one the kernel is loaded from :
$ sudo disklabel -h sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: USB DISK 2.0 duid: d2254a60106318f1 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 487 total sectors: 7831552 # total bytes: 3824.0M boundstart: 32832 boundend: 7831552 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] a: 888.6M 32832 4.2BSD 2048 16384 1 # / b: 256.0M 1852672 swap # none c: 3824.0M 0 unused d: 2282.1M 2376960 4.2BSD 2048 16384 1 # /usr e: 381.3M 7050688 4.2BSD 2048 16384 1 # /home i: 16.0M 64 MSDOS
-
-
-
Could we get a hoax tag for this kind of stuff?
-
-
journeysquid
5 years ago
|
link
| on:
PRISM break, Opt out of PRISM, the NSA’s global data surveillance program
Saying this is some sort of “PRISM opt out” is silly, but it is still a good list of application alernatives. I was not aware of Adblock Edge, or Jitsi as an alternative to Skype.
-
Also note the last part of Theo’s reply to that mail: “ps. Disable Intel Hyper-Threading where not needed, until we all know more.”
After Spectre/Meltdown were disclosed we made a similar decision. Not uniformly: we haven’t disabled it on every one of our physical hosts–we’ve done it where we could. Given the significant chance of further CPU vulnerabilities it seemed like a reasonable decision. Time will tell.