mewmew

Haha, I almost never reply on HN. But the Office Space ref made my day <3

Surprised to see noone has mentioned the use of tinyurl in a .gov document. Those links may be stale, tinyurl.com may be sold, etc, etc.

Perhaps I'm the wrong audience, so feel free to disregard this feedback :)

I personally use Hacker News without JavaScript, and was expecting/hoping the same would work for autonews. But, alas. It gets stuck at "Loading..."

Still, wish you all the best with autonews, and hope you can build a tailored community of automotive enthusiasts.

Cheers, Robin

> It was a real shock to find them there, a really good shock, but we can’t do DNA tests

I'm just curious, why would it not be possible to do DNA tests? Is it too difficult to get to?

>> Rediscover the web that Google "disappeared."

> As it happens we were toying with taglines today and minded to go with these:

I very much like the "rediscover" part. The web has indeed lost it's charm when the results only show Facebook, Twitter and 10 or so other huge sites.

As for tagline, I'd suggest something along the lines of "Rediscover the web and escape your filter bubble!".

Wish you all the best and happy coding!

P.S. I'd be very curious to get insight into if you have considered open sourcing the search engine? This would tie into transparency and trust, and would also enable contributions! I'd love to contribute to my day-to-day search engine, especially if it is privacy respecting!

Also, I second a subscription model for sustainability. I do not want to be the product.

Kind regards, Robin

> The second one is especially hard to grok for non-techies. I have to explain that if you insist on accurate estimates, you will get grossly padded estimates [0]. And the work will expand to fit the time available (sometimes resulting in the task exceeding even the massively padded estimates because the work expanded with the estimate). I've had many entertaining conversations attempting to explain this.

Sounds like Hofstadter's law.

"Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law."

[1]: https://en.wikipedia.org/wiki/Hofstadter%27s_law

From 5.4. Action Plan Timeline - Act Now

> Despite all the negative effects on the health system and the large parts of the economy the corona crisis has worked as a positive image campaign for the entire digital services industry.

> As e-commerce and remote working solutions became widely used and even smartphone tracking to prevent infections met very little scepticism. Now in the aftermath of this pandemic it’s the perfect time to act and to push for ambitious goal in digitalising Europe.

> Long term 2025 – 2030

> Phase 3 of the eGovernment Venture Programme: Implementation of innovations developed in the programme. Officially Launching the European Internet: Similar to the Chinese Firewall.

Thanks for the in-depth write-up @mdasen. I certainly learnt a lot about general GC properties and trade-offs.

takes hat off in appreciation

To give further background, the Devilution team has primarily relied on these resources:

1. The Japanese Playstation port with debug symbols contained in `DIABPSX.SYM`. (see [1]).

Example debug info of the Cathedral dungeon generation algorithm:

  // address: 0x801259D0
  // line start: 612
  // line end:   624
  void DRLG_L1Floor__Fv() {
   // register: 19
   register int i;
   // register: 20
   register int j;
   // register: 3
   register long rv;
  }

2. The debug release of the PE executable, which contained assert strings (see [2]).

Example assert string:

  "plr[myplr].InvGrid[i] <= plr[myplr]._pNumInv"

3. The Rich header of the PE executable, which details the exact version of the original compilers and linkers used to build `Diablo.exe` (see [3,4]).

Example information recovered from the Rich header of `Diablo.exe`:

  Id  Build  Count  Name       Description
   0      0    155  Unknown    [---] Number of imported functions (old)
   1      0    229  Import0    [---] Number of imported functions
   6   1668      1  Cvtres500  [RES] VS97 (5.0) SP3 cvtres 5.00.1668
   2   7303     29  Linker510  [IMP] VS97 (5.0) SP3 link 5.10.7303
   3   7303      1  Cvtomf510        VS97 (5.0) SP3 cvtomf 5.10.7303
   4   8447      2  Linker600  [LNK] VC++ 6.0 SP3,SP4,SP5,SP6 link 6.00.8447
  48   9044     72  Utc12_2_C  [---] VC++ 6.0 SP5 Processor Pack
  19   9049     12  Linker512        Microsoft LINK 5.12.9049

4. Discovery of the original set of compiler flags used to build `Diablo.exe` (see [5]).

Primarily "/O1" was used, but there are also peculiarities such as the use of both Microsoft Visual Studio 6 and Microsoft Visual Code 5 for linking the game.

5. The heartfelt dedication of a team of people. GalaXyHaXz did the initial heavy lifting and succeeded in the tremendous task of getting the decompiled source code of Diablo 1 compiling with the original toolchain. Later on she released the project open source and a community of open source collaborators formed. Most of us have never met in real life prior to joining the project, which stands to show that there is strength in online collaboration that transcend both culture and borders.

6. The Beta release and the Alpha4 release of Diablo 1 has also proved invaluable resources for cross-validation as the compiler optimization level was not set to release mode for these binaries.

Interestingly, in the process a number of bugs in the original implementation of Diablo 1 were discovered. These have been documented in the source code of Devilution with `// BUGFIX: foo` comments, and have also been detailed in [6].

To track the progress of the project, the "Binary identical functions" milestone has been used in tandem with an assembly diffing tool developed in Rust (see [7,8]).

Anecdotally, it was an incredible moment when we first managed to run the cross-platform port of Diablo 1 (DevilutionX, see [9]) natively on Linux and succeeded in playing a multiplayer game connecting our computers in Korea and Denmark. It is equally thrilling to see the modding and porting community picking up the torch and already succeeding in porting Diablo 1 to Nintendo Switch!

The main reason for conducting this bit of software archeology is to preserve the classic title that is Diablo 1, for generations to come. And to revive it for modern hardware platforms and make it more mod-friendly in the age of open source software.

Happy coding! - The Devilution Team

P.S. the project README explicitly states that to play the game, you still need to have access to the original game assets released on the Diablo 1 CD. To acquire a legal copy, please refer to https://www.gog.com/game/diablo

P.P.S. for the verification process, there have been proposals that are both ambitious at a level of PhD research (see [10]) and that made us feel warm and fuzzy <3 In the end, many of the techniques outlined were discussed mostly on a design level, some were included as Proof of Concepts, but most of the work in reverse engineering Diablo 1 was from tender labour of a team that care for Diablo 1 the way you would your firstborn child.

[1]: https://github.com/diasurgical/scalpel/blob/master/psx/_dump...

[2]: http://diablo1.se/notes/debug.html

[3]: https://github.com/diasurgical/devilution/issues/111#issueco...

[4]: http://bytepointer.com/articles/the_microsoft_rich_header.ht...

[5]: https://github.com/diasurgical/devilution/issues/111

[6]: https://github.com/diasurgical/devilution/issues/64

[7]: https://github.com/diasurgical/devilution/milestone/3

[8]: https://github.com/diasurgical/devilution-comparer

[9]: https://github.com/diasurgical/devilutionX

[10]: https://github.com/diasurgical/devilution/issues/171

I've been following the Genode project for quite some time, and first got the chance to meet the Genode team when they presented their work at FOSDEM in 2012. I've since been amazed, both at the pace of development they've kept up while keeping to their principles of a small trusted code base that is kept clean by refactoring when common concepts are outlined.

My friend Daniel and I were invited to join their Hack n' Hike event a few years back, and it was just the loveliest! We hiked together during the days, sharing a barbecue around the camp fire in the evenings and hacking together at night. The people on the Genode team are among the friendliest I've come across in the open source community.

I wish you all the best of futures, both with the Genode project and in life in general.

Cheerful regards, Robin

Edit: the slides from FOSDEM 2012 introducing Genode (in the state of the project back then): https://genode-labs.com/publications/nfeske-genode-fosdem-20...

This is great actually! Thanks a lot for implementing a quick preview feature, perfect for reading an article in one sitting without getting distrcted with side tabs.

This would have been interesting if GDPR was applied.

https://www.gdpr.associates/data-breach-penalties/

"There will be two levels of fines based on the GDPR. The first is up to €10 million or 2% of the company’s global annual turnover of the previous financial year, whichever is higher. The second is up to €20 million or 4% of the company’s global annual turnover of the previous financial year, whichever is higher.

The Parliament had requested for fines to reach €100 million or 5% of the company’s global annual turnover. The agreed fines are the compromise that was reached."

@krasin Thanks! I know I'll continue to play around with LLVM on many levels in life. Just recently an LLVM Socials meetup has started in Sweden, and it feels great to get a chance to meet other people excited about exploring these topics :)

@krasin Thanks for the input. From my understanding ThinLTO is intended to bring compilation speed of LTO builds closer that of non-LTO builds. Prior to the change you are referring to with merged modules, it seems this was achieved by optimizing multiple .bc modules in parallel during link time (using summery information from thin-link) [1].

Is there any high-level information of the design behind merged modules? Are they simply a concatenation of .bc files with a table of file offsets for each module?

I am new to ThinLTO and the work related to merged modules, so any information providing insight would be appreciated.

As for the llir/llvm project. It includes a .ll parser, but relies on the LLVM toolchain for converting .bc files into .ll; i.e.

llvm-dis -o foo.ll foo.bc

This decision has been taken so that we can focus time on maintaining good support for one of the isomorphic LLVM IR forms.

Any application which requires good performance should definitely make use of the official LLVM C++ library for interacting with LLVM IR.

The llir/llvm project is intended for those who wish to write tools in Go which consume, produce, process or manipulate LLVM IR.

Future releases of llir/llvm will try to get closer in performance to the official LLVM C++ library, but at this point of the project the aim is to iron out a good API for interacting with LLVM IR, and to have fun coding :)

For those interested, the llir/llvm project was born to support the requirements of a decompiler project [2] which decompiles LLVM IR to Go source code. The llir/llvm project has since become a general purpose library, and is now looking for anyone curious to try it out at this early stage to provide feedback on its API and design.

[1]: http://blog.llvm.org/2016/06/thinlto-scalable-and-incrementa...

[2]: https://github.com/decomp/decomp

@krasin The LLVM IR assembly language does change with a rather high rate. Not too often to be unfeasible, but an external project definitely needs to make sure it can keep up with maintenance to remain useful. Since the llir/llvm project started back in 2014, the LLVM IR assembly language has had one major change, and that is the new metadata syntax introduced in LLVM 3.6.

To facilitate maintenance efforts over time, a BNF grammar for LLVM IR assembly has been written, from which the lexer and parser are generated [1,2,3]. The intention is for this BNF grammar to eventually become the basis or starting ground for an official BNF grammar of the LLVM IR assembly language (but that's a different project altogether, and a huge effort in itself).

[1]: https://github.com/llir/llvm/blob/master/asm/internal/ll.bnf

[2]: https://github.com/llir/grammar

[3]: https://github.com/goccmack/gocc

The Japanese Playstation 1 release of Diablo 1 did include debug symbols though!

https://github.com/sanctuary/notes/issues/1

The seed is a 32-bit signed integer [1]. Diablo 1 was using the Borland C/C++ pseudo-random number generator algorithm, with a multiplier of 0x15A4E35 and an increment of 1 [2,3]. A Go implementation of the PRNG used in Diablo 1 is located at [4].

So I guess there are 2^31-1 unique dungeons per level. Storing, rather than dynamically generating, these dungeons would require a huge amount of disk space. For each level, a 112x112 two-dimensional array of 32-bit integers is used to store the piece IDs which make up each tile (a tile consists of four pieces) [5], and a 40x40 two-dimensional array of 8-bit integers is used to store the tile IDs [6]. Thus, a total of 51776 bytes (roughly 50 KB) is required to store the contents of each generated dungeon.

In total, more than 100 TB would be required to store the contents of each unique procedurally generated dungeon per level. The game contains 17 levels, so to store each unique dungeon for each level, a storage capacity of about 1.7 PB would be required. This might be possible today, but was definitely a challenge back in 1996.

[1]: https://github.com/sanctuary/notes/blob/master/bss/engine.md... [2]: https://github.com/sanctuary/notes/blob/master/functions/eng... [3]: https://en.wikipedia.org/wiki/Linear_congruential_generator#... [4]: https://github.com/sanctuary/d1/blob/master/rand/rand.go [5]: https://github.com/sanctuary/notes/blob/master/bss/gendung.m... [6]: https://github.com/sanctuary/notes/blob/master/bss/gendung.m...