Reproducible-builds – Provide a verifiable path from source code to binary - <AUTHOR> https://reproducible-builds.org/ <comment><USER2> Reproducible builds can have some unexpected benefits. For example, a package build machine could track compiled files that have changed since it compiled an older version of the software, and store them at the start of the archive when zipping the installable files into package. Then when the user's package manager updates to the newer package, it only has to download enough of it to extract all the files that have changed between versions, thus saving time and bandwidth. Software that builds reproducibly will have fewer gratuitous changes (dates, etc), thus making this process work better.

In fact, OpenBSD's and PC-BSD's package managers do this. It's briefly touched on in the last slide of this talk: [http://www.openbsd.org/papers/eurobsdcon2015-packages.pdf](http://www.openbsd.org/papers/eurobsdcon2015-packages.pdf)

<comment><USER3> Mm. Reproducible builds have a really wide variety technical advantages, including implicitly removing non-deterministic or unsafe behaviour (such as downloading third-party code from the internet), detecting corrupted build environments, reducing time-to-detection of a build host compromise, validating cross-built packages, the potential space/time savings you mention as well as numerous other debugging and testing advantages.

In other words, even if you are an _attacker_ , you want reproducible builds. :)

</comment></comment><comment><USER4> I hadn't seen this spec before: [https://reproducible-builds.org/specs/source- date-epoch/](https://reproducible-builds.org/specs/source-date-epoch/)

Parabola's efforts toward reproducibility have been essentially discarding timestamps by forcing them all to Jan 1, 1990 (a simple date, with a wide gap between it and the Unix epoch) [https://projects.parabola.nu/packages/libretools.git/tree/sr...](https://projects.parabola.nu/packages/libretools.git/tree/src/librefetch/librefetch#n325)

Perhaps I should add support for this to Parabola's toolchain.

<comment><USER5> SOURCE_DATE_EPOCH is useful in those cases where for a reason or another you can't remove timestamps. Initially we wanted to remove everything, but we also noticed it's easier to convince people/upstream to accept the support for SOURCE_DATE_EPOCH than remove the timestamp entirely.

<comment><USER4> The `tar` format requires timestamps; so if the tarball products are to be reproducible, then you need to stick something there.

</comment></comment></comment><comment><USER6> What about the opposite direction: create builds from the same source that use different memory layouts to make the life of attackers harder? I think diversity could create resilience, too. Obviously it makes verification harder.

<comment><USER7> There's various research projects out there to, at compiler level, create different output binaries out of same source code to accomplish this task. I'm not really following it I just remember a professor at my undergrad was recruiting people for his lab on it, and I'm pretty sure his project was not only one. [https://ssllab.org/trac/wiki/MultiCompilerPublic](https://ssllab.org/trac/wiki/MultiCompilerPublic)

edit: see compiler/compile-time randomization? see some other similar projects under these key terms.

</comment></comment><comment><USER8> Reproducible builds are really rather important -- and open up some other possibilities too...

</comment><comment><USER9> weak security cert :\

<comment><USER10> Are you talking about their TLS certificate? SSL Labs[0] gives them an A-, and gives their certificate 100%.

[0]:[https://www.ssllabs.com/ssltest/analyze.html?d=reproducible-...](https://www.ssllabs.com/ssltest/analyze.html?d=reproducible- builds.org)

<comment><USER9> Oh, I probably have an old (bad) StartCom cached on my machine then.

[http://i.imgur.com/diXXwnQ.png](http://i.imgur.com/diXXwnQ.png)

</comment></comment></comment><comment><USER11> What is wrong (non-reproducible) with

      gcc a.c

or any other compiler?

<comment><USER12> See [https://wiki.debian.org/ReproducibleBuilds/Howto](https://wiki.debian.org/ReproducibleBuilds/Howto)

You would probably need to pass in an "-frandom-seed" option and make sure your environment is the same, but I would imagine you can get that to give you a deterministic output fairly easily.

Most of the difficulty comes in the packaging, where you need to make sure that files enter the archive with the same timestamps/permissions, and in the same order.

</comment></comment><comment><USER13> I'm not really sure how to take this recent and emerging narrative that software source code compilation is actually an unreliable, unpredictable activity.

I find it really strange that there's a sudden, intense focus on the premise that, given the same source code, when providing it to different people in the wild and asking them to try and compile it, and then having them share their results, doing so reveals variations and disparities that are difficult to explain or account for.

I know _why_ people are suddenly paying attention to this detail: paranoia.

I remember when I noticed this concept had first started to gain some traction. Once people started trying to compile certain open-source crypto applications, and found that their binaries weren't byte-for-byte replicas, it begged the question: Am I actually encrypting my confidential data with a surreptitiously hobbled program? Is there a covert plot to infiltrate and sabotage these sorts of software projects? How would I know if the encryption was weakened in a subtle way, when I don't have the resources to try and crack it at levels that demand well-funded hardware?

But, I wonder, is this something to worry about everywhere?

Is this why so many projects are now taking on this additional activity?

Is there a panic and an anxiety driving this trend, or are we just crossing dotting our i's and our crossing our t's with yet another set of best practices?

<comment><USER14> We live in an era of viruses, rootkits, botnets, ransomware, adware, spyware, and industrial sabotage. This is at the hands of script kiddies, political activists, criminal networks, corporations, and every nation state with the budget for it - or some close approximation thereof, it seems. Sourceforge has been breached. Debian builds have been breached.

Have you managed to dodge _all_ of the above? I haven't. I've had accounts on at least 4 services which were breached at some point. I've seen viruses, adware, and spyware. I've seen script kiddies in my communities, distributing backdoored executables, gathering passwords, and getting banned. And this is only what has failed to escape my notice.

It's not paranoia if they really are out to get you.

> But, I wonder, is this something to worry about everywhere?

Would it be useful for you to be able to detect when your build machine has been compromised, and starts producing malware laden executables? Reproducible builds are a tool that can potentially do that for you - just diff the binaries.

Whether or not it's worthwhile to set up depends on how much of a pain in the ass making reproducible binaries is. Ongoing research into the subject is interesting, if only because it directly correlates to making it less of a pain in the ass when other people figure it out for you.

> Is there a panic and an anxiety driving this trend, or are we just crossing > dotting our i's and our crossing our t's with yet another set of best > practices?

I wouldn't describe such interest as panic or anxiety - but I wouldn't put it down to merely getting in line with "best practices" either. It's an interesting subject of research - and a potentially useful one at that.</comment></comment>


5 Years at the Internet Archive: The Party - <AUTHOR> http://ascii.textfiles.com/archives/4948 <comment><USER2> Congratulations Jason. Sorry that I won't be able to be there for the party.

The Internet Archive is one of the great non profit institutions and worthy of everyone's support. To donate: [https://archive.org/donate](https://archive.org/donate). To explore _The Archive_ : [https://archive.org](https://archive.org).</comment>


PHP 5.4.0 released - <AUTHOR> http://php.net/downloads.php#v5

<comment><USER2> Big hitters:

array dereferencing - $object->method()[$index] is now valid syntax

built-in webserver via CLI - _php -s_ \- <http://php.net/manual/en/features.commandline.webserver.php>

traits and the insteadof operator - <http://php.net/language.oop5.traits.php>

shortened array syntax - $array = [1, 2, [1, 2, 3], 4];

Finally _removed_ register_globals ;)

Default charset of UTF-8!

Read all about it! <http://www.php.net/manual/en/migration54.php>

<comment><USER3> I am curious what the internal hang up is which prevents:

funcReturnsFunc(1)(2)

<comment><USER4> > I am curious what the internal hang up is which prevents:

PHP's parser is... not exactly a great work of software engineering.

<comment><USER5> > PHP is... not exactly a great work of software engineering.

FTFY. :)

<comment><USER6> You can do better? As smart man as you are surely can figure out where to send the patches.

</comment></comment></comment></comment></comment><comment><USER7> This is a nice list of improvements. As someone who spends a lot of the day in PHP-land, this is going to make me happy. As someone who also controls our entire server stack, waiting for someone else to decide to upgrade will not be a problem :)

I'm glad the PHP devs are starting to actually make it a "real" language. It seems like PHP has always been the fat kid bumbling along behind everyone shouting "wait up guys!!" With closures in 5.3, syntax improvements and removal of _horrible_ features (register_globals, magic_quotes, etc) in 5.4, it's shaping up quite nicely.

Thanks, PHP devs!

<comment><USER8> > waiting for someone else to decide to upgrade will not be a problem :)

It is sad that a lot of servers are not like this, and PHP 5.4 will take ages to appear, if at all.

Heck, I know of a hosting company still using PHP4.

<comment><USER9> Hosting company that still uses PHP4? Name names so we can avoid and chastise them!

<comment><USER10> Media Temple for one. For a domain or subdomain you had to explicitly choose PHP5 instead of the default PHP4.

<comment><USER11> They actually changed this recently. The default is now PHP5, with an option to select PHP4.

</comment></comment></comment></comment></comment><comment><USER12> They also improved the zend engine, CURL extension, added Tokyo cabinet abstract and Berkeley DB Support! Added a couple of hashes, Improved JSON Extension (JSON_NUMERIC_CHECK!) and a whole lot of bug fixes. The UTF-8 part was long overdue, glad they fixed that.

I spend a lot of time programming in PHP. Its reputation is pretty bad, but updates like this keep me going!

<comment><USER13> PHP was my first love (actually my second, after QBasic) when I was a teenager.

Would love to get back into it now that it's a "real" language.

Got any good tips about books on modern PHP programming?

<comment><USER12> Books... not so much. I have another idea: you could check out an MVC- framework like codeigniter or CakePHP. There are numerous tutorials about them, and they give you the added benefit of working with an MVC pattern (knowledge you can use in other languages and frameworks as well, such as Ruby on Rails) and working Object Oriented.

In my opinion, a big drawback of PHP is that it's so easy to screw up because it's easy to pick up. There are so many tutorials out there which will let you make a procedural, cross-scripted, sql-injected security liability spaghetti code... Starting with CodeIgniter or CakePHP is not very hard, especially when you have a little understanding on basic programming with PHP. Good luck!

<comment><USER14> CodeIgniter and CakePHP are great examples of code badly brought forward into PHP5 from PHP4 roots. I wouldn't recommend either to either a novice or an expert; CodeIgniter is a fantastic example of out-of-date practices and CakePHP an example of writing such abjectly slow code that everybody else benchmarks against you to look good.

If you're going to use PHP5, Symfony2 is a well-reasoned, best-of-breed system.

<comment><USER15> I'd also recommend Kohana. It was originally a fork of CodeIgniter, but version 3.0 was a complete rewrite for PHP5. Compared to Symfony, it's more of a barebones framework.

<comment><USER14> I wouldn't. Kohana's track record of cavalier response to security concerns is off-putting and their code is not particularly impressive.

There's a reason people who use PHP are getting on @fabpot's train and not Kohana's, and that's because Symfony2 does much, much more _right_ than anyone else in the conversation.

</comment></comment></comment></comment></comment></comment><comment><USER16> Other great little changes:

      - you can now do function()[0]
      - <?= always on despite what you say in the INI
      - safe_mode always off

Seems like a return to sanity for the PHP team, at least temporarily.. I even kinda like the traits!

<comment><USER17> How is '<?=' being always on great change? I always thought it was weird and kind of stupid, but I'm genuinely curious how is that great thing.

Also,

      Chained string offsets - e.g. $a[0][0] where $a is a string - now work.

I have no idea how is that supposed to work. What should be the outcome on, say:

      $a = "foo"; $a[0][0]

What about (assuming $a is still "foo"):

      $a[0][1]

etc.?

<comment><USER18> > How is '<?=' being always on great change? I always thought it was weird and > kind of stupid, but I'm genuinely curious how is that great thing.

When you share your code with various clients (open source, software seller, ...), you can not assume that short array are on, thus you have to use <?php echo $var ?> everytime instead of the shorter <?=$var?>. Having the second syntax always working solves that, this is on the same level as the short array syntax change, removing a hurdle and letting you concentrate on more important stuff.

> $a = "foo"; $a[0][0]

$a is a string "foo" $a[0] is a string "f" equating to substr($a, 0, 1) $a[0][0] is a string "f" equating to substr($a[0], 0, 1)

> $a[0][1]

This will give an undefined index error, same thing as $a[42] for exemple, since index 1 doesn't exists in $a[0] (= "f")

<comment><USER19> > thus you have to use <?php echo $var ?> everytime instead of the shorter > <?=$var?>

Is this really a huge concern? I guess I just have $tockholm syndrome at this point, and am used to writing <?php echo $var; ?> explicitly every time, precisely for the reasons you mentioned. It's one less thing to worry about.

</comment></comment></comment></comment><comment><USER20> They finally added short array syntax, removed register_globals and magic quotes, and the default character set is now UTF-8!

This is good news indeed, they seem to be actually improving the language for once.

</comment><comment><USER21> Seems like the multiyear unit-test coverage campaign is starting to pay off for the core PHP engineers, 5-6 years ago they swore they couldn't do shortened array syntax without major problems.

</comment><comment><USER22> Also awesome:

"Arrays cast from SimpleXMLElement now always contain all nodes instead of just the first matching node. All SimpleXMLElement children are now always printed when using var_dump(), var_export() and print_r()."

</comment><comment><USER23> I'm glad to see the short array syntax. Having strayed from PHP for a while to work on Ruby and JavaScript I'm really enjoying the ability to leave out semicolons in unambiguous end-of-line situations. Would love to see that make it into PHP at some point.

<comment><USER24> The best part of short array syntax is that now you don't need named parameters to be supported by the language.

        function foo($opts) {
          echo $opts['source'] . $opts['destination'];
        }

        // just one extra pair of [] needed instead of new array()
        foo(['source' => '/123', 'destination' => '/abc']);

<comment><USER25> While I agree that it makes it easier to hack in that functionality, it would still be very useful to have named parameters for functions that don't implement that functionality.

For example, fgetcsv takes parameters for delimiter, enclosure, and escape char (as of 5.3). Right now, if I want to specify a different enclosure, I'm forced to specify a delimiter even if I still want to use the default. I'd much prefer the ability to tell the function call that I want to override the enclosure and leave the delimiter alone.

<comment><USER24> > While I agree that it makes it easier to hack in that functionality, it > would still be very useful to have named parameters for functions that don't > implement that functionality.

Absolutely. But PHP devs have repeatedly refused to support named parameters so this is a good enough fix.

<comment><USER19> > this is a good enough fix.

The story of PHP's life.

</comment></comment></comment></comment></comment><comment><USER26> From here: <http://www.php.net/manual/en/migration54.other.php>

> Chained string offsets - e.g. $a[0][0] where $a is a string - now work.

Can someone explain why this is? I'm sure I'm misunderstanding, but this seems to mean that the following would work:

      $a = "Hello";
      echo $a[0]; //"h"
      echo $a[0][0]; // also "h"??

What's the point? To avoid failure if I pass a string instead of a 2-dimensional array?

<comment><USER27> Consistency. Since $a[0] is a string, you would expect $a[0][0] to work too.

<comment><USER26> Thanks. Let me rework my original question then. Why the hell didn't it always work?

      php > $a = "Hello";
      php > echo $a[0];
      H
      php > echo $a[0][0];
      PHP Fatal error:  Cannot use string offset as an array in php shell code on line 1

<comment><USER16> PHP always seemed to have something weird in the parser about subscripts/array indexes. It's been there since I started using it during PHP3. Another similar fix they performed is making func()[0] work - before you had to do $tmp = func(); $tmp[0]. An old, old bug finally fixed.

</comment></comment></comment></comment><comment><USER27> Closures can now have a `$this` (by default it is the class in which the closure is declared). No more $that = $this hacks :)

<comment><USER28> There's also Closure::bindTo() [0], which should allow you do do slightly more functional programming, like JavaScript's Function.apply() [1]

[0] <http://docs.php.net/manual/en/closure.bindto.php>

[1] [https://developer.mozilla.org/en/JavaScript/Reference/Global...](https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Function/apply)

</comment></comment><comment><USER29> These features can only be good for PHP. Now the community needs to step up and care for the language better. We have seen the popularity of many languages and frameworks rise and fall, but php keeps chugging along. Modern frameworks are awesome, but the community is still rather fractured. I would love to see people more proud of php, to get over the fads around them. Now the language is getting some nice features, I think it's our time to shine :)

</comment><comment><AUTHOR> Here are the NEWS text: [http://svn.php.net/viewvc/php/php- src/tags/php_5_4_0/NEWS?re...](http://svn.php.net/viewvc/php/php- src/tags/php_5_4_0/NEWS?revision=323659&view=markup)

and the UPGRADING instructions: [http://svn.php.net/viewvc/php/php- src/tags/php_5_4_0/UPGRADI...](http://svn.php.net/viewvc/php/php- src/tags/php_5_4_0/UPGRADING?revision=323659&view=markup)

</comment><comment><USER30> Can it add hex now?

<https://bugs.php.net/bug.php?id=61095>

<comment><USER31> the ticket says Closed, so it better do.

</comment></comment><comment><USER32> They shipped it with 82 failing tests.

<http://gcov.php.net/viewer.php?version=PHP_5_4>

Why even bother having a test suite?

<comment><USER33> I'm not sure what's more worrying:

* 82 failing tests

* 44 _expected_ test failures

* 1119 compiler warnings

I want to believe that PHP is growing up, but I have to admit I'm not convinced.

</comment></comment><comment><USER34> One thing that's pretty important too is PHP-FPM. I've been dreaming about this for a long time for my nginx deployments.

<http://php-fpm.org/>

<comment><USER35> Hasn't PHP-FPM been part of the PHP core for a while now? Since 5.3.3 (mid 2010) according the PHP FPM site.

<comment><USER36> Yes but has of 5.4 it is now considered stable, whereas before it was still experimental (even tho it worked fine).

</comment></comment></comment><comment><USER37> When will this be available for FreeBSD? I really can't wait for traits, short array syntax and "foo()[0]". This is really a nice upgrade. Good job PHP team!

</comment><comment><USER38> Are there any benchmarks (synthetic or real-world) for the performance improvements? Would have been nice if the release notes had provided some.

<comment><USER39> There are some around like <http://news.php.net/php.internals/57760>, seen a couple more but forget where. The trend does seem to be towards far better performance across the board though which is good.

</comment></comment><comment><USER40> I see a lot of mentions of zend in extension names, function names.. Could someone elaborate how Zend relates to PHP?

<comment><USER12> Zend developed the Zend Engine, a virtual machine. PHP4 is based on the Zend engine. Zend is more than just the framework, it literally is the core of PHP.

</comment></comment><comment><USER41> array dereferencing - $object->method()[$index] is now valid syntax

finally ....

<comment><USER41> shortened array syntax - $array = [1, 2, [1, 2, 3], 4]; ..... can't express how long i waited for these

</comment></comment><comment><USER42> Added callable typehint.

Nice

<comment><USER43> Oh that's a nice one I hadn't noticed yet. Now all that's left is type hints for scalars...

</comment></comment><comment><USER44> Now the question is, when will this become available in mainstream Linux distributions? I guess Arch et al. will get it pretty quickly, followed by Ubuntu 12.10 or maybe 13.04 depending on how many packages it affects.

Good ol' Debian, on the other hand, might or might not get it in time for the Wheezy freeze. CentOS? Forgetaboutit.

<comment><USER45> You mention two distros that are designed for stability. Thats very different from following the bleeding edge and they have their purpose and reason for it(Which while developers like myself and I assume you sometimes forget, our server admin friends never do). If you want to follow the leading edge there is always also the option of making your own packages.</comment></comment>


Alacritty – Fastest OS X Terminal Emulator – Terminal like tmux/alacritty config - <AUTHOR> https://bradbarrows.com/post/alacritty <comment><USER2> Apple Terminal and kitty both have less latency than Alacritty. Alacritty being "the fastest" may just be a marketing gimmick.

[https://thume.ca/2020/05/20/making-a-latency- tester/](https://thume.ca/2020/05/20/making-a-latency-tester/)

</comment><comment><USER3> Were the latency issues addressed?

[https://lwn.net/Articles/751763/](https://lwn.net/Articles/751763/)

</comment><comment><USER4> last time I tried it, any speed gain from Alacritty has been made moot from having to use tmux on OSX just to have even the most basic functionality of window management.. has there been any improvement on that side?

<comment><USER5> I switched to Alacritty+tmux on macOS about 2 months back. The only complaint I have is a tmux one (nested tmux sessions suck.)

Curious, what are the limits you see with having to use tmux?

<comment><USER4> Not that theres a particular limit, just that its unbearably slow. To the point of it being pretty much unusable if you spend significant time of your work in a terminal text editor.

This is an issue with tmux on macos to be clear, not with alacritty, but it kinda is related as alacritty doesn't come with any window management features so you kinda have to use tmux..

Just checked out the project repo, seems like the warning is still there on the faq[1], so I'm guessing it is still the same.

[1]([https://github.com/alacritty/alacritty#faq](https://github.com/alacritty/alacritty#faq))

</comment></comment></comment><comment><USER6> Alacritty is slower than the standard terminal, has none of the nice features of iTerm, doesn't even support tabs.</comment>


Climate Change: Luxury Holidays and SUVs Are Badges of Shame Now - <AUTHOR> https://www.bloomberg.com/opinion/articles/2019-06-21/climate-change-luxury-holidays-and-suvs-are-badges-of-shame-now <comment><USER2> Well I hope I helped with those big assed SUVs becoming a badge of shame. I've worked at it since the early 2000s.

That bloated junk they make now is made to appeal to giant egos and it amazes me how many there are out there. I miss the days when you could lift a 5 gallon bucket or some tools over the tailgate or side of the bed of a pickup truck.

My favorite car, of all those I've owned, is the Suzuki Samurai 4x4. The Suzuki Sidekick/Chevy Tracker is next. After that would be `70-`80's era Toyota Pickups. You can't buy anything new like those now.

</comment><comment><USER3> I'm driving a Prius and feeling very smug and superior about it. :P Saving up for a model 3 though.

</comment><comment><USER4> This is an ad for VW</comment>