So funny. Just a few short years ago, Mozilla explicitly declined to support H.264 on Windows, even if there was a free native plugin, since it'll partition the Linux users.
And now they're deciding to support DRM, just to keep the market share?
OpenSSL has basically wrote their own version of libc, and all the functions they've introduced differ is some very subtle ways from what appears in libc used by the rest of the world.
Rest assured, OpenBSD is no stranger to portable code. Just take a look at the number of platforms they support -- http://www.openbsd.org/plat.ht....
OpenBSD's OpenSSH has a separate portability layer, and they're doing just fine without the extra malloc wrappers. And no big-endian x86 support, either!
You're referring to the exploit-mitigation-mitigation in OpenSSL, which indeed couldn't be disabled, as per tedu@openbsd, but OPENSSL_NO_HEARTBEATS was a separate option that noone has volunteered to claim of not working.
OPENSSL_NO_HEARTBEATS has since been made the default and only option in LibreSSL, and the heartbeats were removed.
Didn't Target already had Chip and Pin back in 2005 or 2004? What happened to all of those?
I remember I got a Chip and Pin card from Fleet around that time (just on the edge of them being acquired by B of A); Fleet has even sent me a free card reader, which I've never used, actually.
What pisses me most about AT&T U-verse is that they do have FTTU (fibre-to-the-user) / FTTP, but they limit FTTP users to speeds that are lower than what they offer through VDSL through FTTN.
I used to live in San Jose, CA in 2010/2012, in a brand new apartment complex, had AT&T U-verse fibre strand terminated in my bedroom closet with an ONT. The line was FTTP-BPON (622/155 1:32), e.g. 622Mbps down / 155Mbps up, shared with at most 32 users, I checked with the manufacturer of my particular ONT.
But AT&T would only provision me with 18/1.5. They'd offer 24/3 to VDSL users only, supposedly too lazy to update the fibre profiles to offer it to the fibre customers. I researched it, and it was not unique to my building or to California, they were doing it all across the country with every single BPON build. My T-Mobile HSPA+ had higher upload speeds than 1.5Mbps on my top-of-the-line AT&T FTTU through BPON.
Keep in mind that the 622/155 line can only be shared with at most 32 users, and some wouldn't even want the top-of-the-line plans, either, or would not have active service in the first place, so, they're basically wasting their own capacity, and refusing an extra 10$/mo from me. Ping time was sometimes about 3ms to some locations within the Bay Area, but the 1.5Mbps bandwidth was pretty pathetic for a BPON fibre line.
I was so pissed I started a whole web-site dedicated to showing how uncompetitive AT&T internet offerings are compared to the options elsewhere in the country -- http://bmap.su/. So happy Google Fiber has finally been announced for San Jose, CA and lots of other markets now! I'm willing to be it'll be some other provider that'll offer broadband to my past place before AT&T will get to their senses and starts using at least the BPON infrastructure that they already have in place.
CBC News Posted: Oct 19, 2004 6:06 PM ET Last Updated: Oct 20, 2004 6:41 AM ET
A justice of the peace has ruled that a "no left turn" sign in Toronto is unenforceable because it is not written in both English and French.
The ruling Monday by justice of the peace Alice Napier could result in thousands of traffic tickets being dismissed.
Lawyer Jennifer Myers argued that a traffic sign in downtown Toronto violated the Highway Traffic Act and the French Language Services Act because it was not in both official languages.
Napier agreed at a night court hearing Monday, and threw out a ticket issued to Myers for making an illegal left turn. Myers does not speak French.
Daniel Brown, a law student who represented her in court, said Myers' victory could prove expensive for the city of Toronto.
I've personally tried testing it out sometime around 2009 or 2010 -- violating illegal no-turn signs on purpose, which are still plentiful in Toronto.
I could not succeed -- the was so much traffic during the hours where the left turns are prohibited, that stopping at a small intersection, to violate the sign, is simply impossible, since everyone will (rightfully) start honking at you in no time!
For what it's worth, it would seem like [a different kind of?] a package signature system was actually supported since 2010, it's just that the official packages were never signed.
And why would you do that? Going that way you're easily MITM'ed.
Can you give some better reason than 'everyone does it'?
Why exactly would you prefer an insecure transmission channel over a reasonably secure one, for the software you install? How does that even remotely fit the OpenBSD mindset?
Maybe it doesn't, but that's not a good reason to claim of a widespread practice, "in OpenBSD land", that's completely foreign to anyone actually familiar with OpenBSD.
I repeat: I don't know of anyone who compiles software from ports all the time (besides, that's not that much more secure, since the ports tree itself isn't signed, either). A `pkg_add` from a nearby mirror is what gets things done for the vast majority of people. Many mirrors are run by developers; personally, I wouldn't use any mirror that wasn't; and yes, especially in light of the recent revelations, this does leave some room for a Government-in-the-Middle attack, which is probably exactly the reason of why this won't be as it was anymore.
Using binary package is just considered not the right way to do things, in OpenBSD land.
Entirely false. Binary packages, installed with pkg_add from a nearby mirror, has been the recommended way to install ports for as long as I remember (I've been a user for some 10 years, and a developer, too). I've never heard of anyone compiling packages directly from ports in OpenBSD. Not even the developers, unless they're port developers, that is.
Even for the kernel itself, it is highly recommended for non-developers to only run the binary snapshots.
Unless one is tracking the stable branch, which has no official binary builds, then compiling from source tree is only ever advised for the developers.
On i386, OpenBSD 5.4 can be installed from either one of the 3 floppies:
%ftp ftp://ftp.nluug.nl/pub/OpenBSD/5.4/i386/ ...
ftp> ls floppy*
150 Here comes the directory listing.
-rw-r--r-- 1 500 450 1474560 Jul 30 18:27 floppy54.fs
-rw-r--r-- 1 500 450 1474560 Jul 30 18:27 floppyB54.fs
-rw-r--r-- 1 500 450 1474560 Jul 30 18:27 floppyC54.fs
226 Directory send OK.
Which one do you use? You'd have to see which one supports your hardware, which is documented in the INSTALL.i386 file, generated from src/distrib/notes/i386/hardware, amongst other files:
Drivers for hardware marked with [A] are NOT included in floppy A.
Drivers for hardware marked with [B] are NOT included in floppy B.
Drivers for hardware marked with [C] are NOT included in floppy C.
In summary, it would seem like OpenBSD is only intended to be boot-strapped from a floppy (e.g. to fetch the rest of the files from the network), and from a single floppy at that. So, even with the licence aside, including something like gnupg is indeed unrealistic and cumbersome.
Not sure, but OpenBSD has this at the very end of its main():
while (1)
tsleep(&proc0, PVM, "scheduler", 0); /* NOTREACHED */
I tried finding the FreeBSD equivalent, but their (Newbus?) code makes it entirely non-obvious where the loop is. Feel free to try your luck — only the comment to what the startup function is supposed to do matches, but the rest is quite unique, even a different function name — mi_startup() on FreeBSD.
When sitting in that job interview with a prospective employer, you can't even be coy about what you used to make, since the new employer can just look it up on Buffer's site... "oh, you made $128k at Buffer. We'll pay you $129k"
Except your actual sample number is wrong -- you must not have read the original post. They're hardly even paying anyone the market rates for SF. Their highest paid engineer, a "senior" one at that, is only getting $107,9k, in SF!
So, it's more like, "oh, you made a $96k at Buffer? We'll pay you $97k"
Although on the other hand, for a gaining company, it's also a matter of providing competitive compensation for employee retention purposes, so, even if your old salary is posted somewhere, a new company isn't necessarily going to employ you at the lowest possible cost, since the likelihood of you leaving for competitive pay would be higher, and turnover is expensive.
Slashdot Mirror
So funny. Just a few short years ago, Mozilla explicitly declined to support H.264 on Windows, even if there was a free native plugin, since it'll partition the Linux users.
And now they're deciding to support DRM, just to keep the market share?
OpenSSL has basically wrote their own version of libc, and all the functions they've introduced differ is some very subtle ways from what appears in libc used by the rest of the world.
Rest assured, OpenBSD is no stranger to portable code. Just take a look at the number of platforms they support -- http://www.openbsd.org/plat.ht....
Like the big-endian x86 support in OpenSSL?
OpenBSD's OpenSSH has a separate portability layer, and they're doing just fine without the extra malloc wrappers. And no big-endian x86 support, either!
https://youtu.be/GnBbhXBDmwU
Well, I can't confirm they did it back in 2001, but I do recall they were still on it in 2005 or so.
It could prevent the security breach -- in England, Chip and PIN cards cannot be swiped in the presence of a Chip and PIN terminal.
But, yeah, it's kinda funny how things turn out. :-)
patch -p0 < 005_openssl.patch.sig
I just tweeted him to ask if he'll be switching back to OpenBSD now. :-)
https://twitter.com/Mcnst/stat...
(DJB is known as @hashbreaker on Twitter.)
5.5 base signify pubkey: RWRGy8gxk9N9314J0gh9U02lA7s8i6ITajJiNgxQOndvXvM5ZPX+nQ9h
5.5 fw signify pubkey: RWTdVOhdk5qyNktv0iGV6OpaVfogGxTYc1bbkaUhFlExmclYvpJR/opO
5.5 pkg signify pubkey: RWQQC1M9dhm/tja/ktitJs/QVI1kGTQr7W7jtUmdZ4uTp+4yZJ6RRHb5
http://meta.unix.stackexchange...
You're referring to the exploit-mitigation-mitigation in OpenSSL, which indeed couldn't be disabled, as per tedu@openbsd, but OPENSSL_NO_HEARTBEATS was a separate option that noone has volunteered to claim of not working.
OPENSSL_NO_HEARTBEATS has since been made the default and only option in LibreSSL, and the heartbeats were removed.
Didn't Target already had Chip and Pin back in 2005 or 2004? What happened to all of those?
I remember I got a Chip and Pin card from Fleet around that time (just on the edge of them being acquired by B of A); Fleet has even sent me a free card reader, which I've never used, actually.
If anyone's looking to grok it and potentially get involved, there's a fast OpenGrok available:
http://bxr.su/o/lib/libssl/src...
What pisses me most about AT&T U-verse is that they do have FTTU (fibre-to-the-user) / FTTP, but they limit FTTP users to speeds that are lower than what they offer through VDSL through FTTN.
I used to live in San Jose, CA in 2010/2012, in a brand new apartment complex, had AT&T U-verse fibre strand terminated in my bedroom closet with an ONT. The line was FTTP-BPON (622/155 1:32), e.g. 622Mbps down / 155Mbps up, shared with at most 32 users, I checked with the manufacturer of my particular ONT.
But AT&T would only provision me with 18/1.5. They'd offer 24/3 to VDSL users only, supposedly too lazy to update the fibre profiles to offer it to the fibre customers. I researched it, and it was not unique to my building or to California, they were doing it all across the country with every single BPON build. My T-Mobile HSPA+ had higher upload speeds than 1.5Mbps on my top-of-the-line AT&T FTTU through BPON.
Keep in mind that the 622/155 line can only be shared with at most 32 users, and some wouldn't even want the top-of-the-line plans, either, or would not have active service in the first place, so, they're basically wasting their own capacity, and refusing an extra 10$/mo from me. Ping time was sometimes about 3ms to some locations within the Bay Area, but the 1.5Mbps bandwidth was pretty pathetic for a BPON fibre line.
I was so pissed I started a whole web-site dedicated to showing how uncompetitive AT&T internet offerings are compared to the options elsewhere in the country -- http://bmap.su/. So happy Google Fiber has finally been announced for San Jose, CA and lots of other markets now! I'm willing to be it'll be some other provider that'll offer broadband to my past place before AT&T will get to their senses and starts using at least the BPON infrastructure that they already have in place.
You remind me of http://www.cbc.ca/news/canada/...
CBC News Posted: Oct 19, 2004 6:06 PM ET Last Updated: Oct 20, 2004 6:41 AM ET
A justice of the peace has ruled that a "no left turn" sign in Toronto is unenforceable because it is not written in both English and French.
The ruling Monday by justice of the peace Alice Napier could result in thousands of traffic tickets being dismissed.
Lawyer Jennifer Myers argued that a traffic sign in downtown Toronto violated the Highway Traffic Act and the French Language Services Act because it was not in both official languages.
Napier agreed at a night court hearing Monday, and threw out a ticket issued to Myers for making an illegal left turn. Myers does not speak French.
Daniel Brown, a law student who represented her in court, said Myers' victory could prove expensive for the city of Toronto.
I've personally tried testing it out sometime around 2009 or 2010 -- violating illegal no-turn signs on purpose, which are still plentiful in Toronto.
I could not succeed -- the was so much traffic during the hours where the left turns are prohibited, that stopping at a small intersection, to violate the sign, is simply impossible, since everyone will (rightfully) start honking at you in no time!
It has been confirmed:
The MPEx Bitcoin stock exchange (run by Mircea Popescu) is listed on the significant contributors page.
Also, according to Bob Beck, director of OpenBSD Foundation, 100k has been raised so far; their target goal for 2014 fundraising is 150k:
http://www.openbsdfoundation.org/campaign2014.html
For what it's worth, it would seem like [a different kind of?] a package signature system was actually supported since 2010, it's just that the official packages were never signed.
http://www.openbsd.org/faq/faq15.html#PkgSig
Revision 1.71:
Sat Jul 17 09:02:47 2010 UTC (3 years, 6 months ago) by ajacoutot
Changes since revision 1.70: +65 -1 lines
Add a "Package signatures" section to teach people how to create and use
signed packages. Still opened for enhancement but all info is there now.
http://openbsd.org/faq/faq15.html#Ports
"Everyone is encouraged to use the pre-compiled binary packages."
And why would you do that? Going that way you're easily MITM'ed.
Can you give some better reason than 'everyone does it'?
Why exactly would you prefer an insecure transmission channel over a reasonably secure one, for the software you install? How does that even remotely fit the OpenBSD mindset?
Maybe it doesn't, but that's not a good reason to claim of a widespread practice, "in OpenBSD land", that's completely foreign to anyone actually familiar with OpenBSD.
I repeat: I don't know of anyone who compiles software from ports all the time (besides, that's not that much more secure, since the ports tree itself isn't signed, either). A `pkg_add` from a nearby mirror is what gets things done for the vast majority of people. Many mirrors are run by developers; personally, I wouldn't use any mirror that wasn't; and yes, especially in light of the recent revelations, this does leave some room for a Government-in-the-Middle attack, which is probably exactly the reason of why this won't be as it was anymore.
Using binary package is just considered not the right way to do things, in OpenBSD land.
Entirely false. Binary packages, installed with pkg_add from a nearby mirror, has been the recommended way to install ports for as long as I remember (I've been a user for some 10 years, and a developer, too). I've never heard of anyone compiling packages directly from ports in OpenBSD. Not even the developers, unless they're port developers, that is.
Even for the kernel itself, it is highly recommended for non-developers to only run the binary snapshots.
Unless one is tracking the stable branch, which has no official binary builds, then compiling from source tree is only ever advised for the developers.
On i386, OpenBSD 5.4 can be installed from either one of the 3 floppies:
%ftp ftp://ftp.nluug.nl/pub/OpenBSD/5.4/i386/
...
ftp> ls floppy*
150 Here comes the directory listing.
-rw-r--r-- 1 500 450 1474560 Jul 30 18:27 floppy54.fs
-rw-r--r-- 1 500 450 1474560 Jul 30 18:27 floppyB54.fs
-rw-r--r-- 1 500 450 1474560 Jul 30 18:27 floppyC54.fs
226 Directory send OK.
Which one do you use? You'd have to see which one supports your hardware, which is documented in the INSTALL.i386 file, generated from src/distrib/notes/i386/hardware, amongst other files:
Drivers for hardware marked with [A] are NOT included in floppy A.
Drivers for hardware marked with [B] are NOT included in floppy B.
Drivers for hardware marked with [C] are NOT included in floppy C.
In summary, it would seem like OpenBSD is only intended to be boot-strapped from a floppy (e.g. to fetch the rest of the files from the network), and from a single floppy at that. So, even with the licence aside, including something like gnupg is indeed unrealistic and cumbersome.
I cannot find a back reference right now, but didn't DJB switch away from FreeBSD to Ubuntu precisely because of the signed packages?
Best course of action is to disable the autoupdate. The whole notion of automatic updates just doesn't make any sense.
Which one does the Linux kernel use?
Not sure, but OpenBSD has this at the very end of its main():
while (1)
/* NOTREACHED */
tsleep(&proc0, PVM, "scheduler", 0);
I tried finding the FreeBSD equivalent, but their (Newbus?) code makes it entirely non-obvious where the loop is. Feel free to try your luck — only the comment to what the startup function is supposed to do matches, but the rest is quite unique, even a different function name — mi_startup() on FreeBSD.
How do you know they've verified your old salary via a background check?
When sitting in that job interview with a prospective employer, you can't even be coy about what you used to make, since the new employer can just look it up on Buffer's site... "oh, you made $128k at Buffer. We'll pay you $129k"
Except your actual sample number is wrong -- you must not have read the original post. They're hardly even paying anyone the market rates for SF. Their highest paid engineer, a "senior" one at that, is only getting $107,9k, in SF!
So, it's more like, "oh, you made a $96k at Buffer? We'll pay you $97k"
Although on the other hand, for a gaining company, it's also a matter of providing competitive compensation for employee retention purposes, so, even if your old salary is posted somewhere, a new company isn't necessarily going to employ you at the lowest possible cost, since the likelihood of you leaving for competitive pay would be higher, and turnover is expensive.