This is a pure 6510 assembly program for the Commodore 64 made by Bright Pixel in 2019, because why not. The C64 was a famous 8-bit machine in the 80s and the highest-selling single computer model ever. Its hardware and architecture set it appart from other 8-bit personal computers at the time. Unlike most of the others, the C64 had dedicated advanced MOS chips for graphics and sprites (the VIC-II), sound (the SID), I/O (the CIA), and many others. These chips were not only powerful for the time, but they could perform their tasks autonomously, independently of what the main CPU, a MOS technology 6510 microprocessor, was doing. For instance, the VIC-II could generate interrupts on automatic sprite collisions. The CPU and the other chips also shared common data and memory BUSes. To cope with all these chips inside 64Kbytes of addressable memory, the C64 had something called memory overlay, in which different chips would access different physical data locations for the same memory address. For instance the $D000-$DFFF block could be used for RAM, I/O or access to Character ROM, by the CPU, depending on a $0001 setting. Chips would have to be turned on or off, or instructed to look for data at specific RAM/ROM locations all the time to make the most of the machine as a whole. This was impressive in the 80s, for a relatevily cheap mass-market personal computer. Programming the C64 was more than a lot of fun, it was a form of art. Because of the way all this hardware was packed together, handling the machine meant knowing its memory map and registers by heart, and dominating quite a collection of tricks, some of which weren’t documented at all. What ended up being written for the C64 by the fervent community of developers all over the world went way beyond the imagination of Jack Tramiel. Today, in 2019, the cult is still alive. There are vast groups of developers still writing C64 games and demos, restoring and using old machines, or using emulators. The SID sound chip was so revolutionary that it still drives a community of chiptune artists all over the world. The High Voltage SID Collection has more than 50,000 songs archived and growing. At Bright Pixel, we like to go low-level, and we think that understanding how things work down there, even if we’re talking about a 40 years old machine, is enriching, helps us become better computer engineers and better problem solvers. This is especially important in a time when we’re flooded with hundreds of high-level frameworks that just “do the job.” Until they don’t. This is a simple demo for the C64: It was coded entirely in 6510 assembly. It makes use of the VIC-II graphics, character ROM and sprites. It plays music using the SID chip. Uses raster-based interrupts, perfectly timed. Implements a random number generator. You can download the source code for it in this repository, change it and run it a real machine or an emulator. The code is all annotated, and you can use the issue tracker to ask us questions or make suggestions, we’ll be listening. Setup Assembler We used the Kick Assembler to build the PRG from the source. KA is still maintained up unti

Throughout much of 2019, Internet tech giant Google has attempted to portray itself as a public champion of web privacy. Yet, behind the scenes, a very different view of Google is emerging. In August 2019, at approximately the same time that Google was rolling out its much-hyped “Privacy Sandbox” privacy framework, it was also working to block efforts of the World Wide Web Consortium (W3C) standards body to bolster the web privacy features of new technical specifications. Google’s efforts to limit the web privacy powers of PING Most notably, Google was the only member of the W3C to vote “No” to a proposed charter change for the Privacy Interest Group (PING), a working group of the W3C dedicated to web privacy matters. Concerned that web privacy issues were being routinely ignored by many working groups of the W3C, the Privacy Interest Group sought to expand its charter, such that it would have the ability to block any new technical specification that it felt would have negative implications for web privacy. PING, for example, had earlier voiced its concerns about the Internet of Things (IoT), and how new IoT web standards failed to address important web privacy issues. In response to the vote request on changing the PING charter, 24 W3C members voted “Yes” and Google (via its parent company, Alphabet, Inc.) was the only member to vote “No.” Since the W3C is based on a system of consensus, even a single “no” vote was enough to veto the proposal. Some have compared the voting system of the W3C to that of the UN Security Council, where even a single “no” vote from a member like the United States, Russia or China is enough to veto a proposal. Thus, Google basically torpedoed a well-intentioned effort to inject a discussion of web privacy into more of the technical working groups of the W3C with a single vote. The 24-1 vote would seem to clearly indicate that Google is not quite as serious about web privacy matters as it would like the public to believe, and that Google is becoming increasingly isolated in its policy stances. That’s especially the case, given that Google has worked time and time again to preserve the ad tracking powers of web cookies, warning that an eliminated of ubiquitous ad-tracking cookies would mean the end of the web as we know it. And, as might be expected, as soon as word of the 24-1 vote on the status of PING began to leak to the media, Google went into full damage control mode. According to Google, it is simply not the case that they are against PING or against new web privacy measures. Rather, it is the case that Google is against the “sweeping powers” of an “authoritarian review group” that might “cause significant unnecessary chaos in the development of the web platform.” In short, Google says that it is the voice of reason here, fighting against the creeping powers of an “authoritarian” tech body. Google vs. the W3C It now appears that Google is attempting to impose its own web privacy ideas on the W3C, and will simply use its equivalent of a “veto” to block any efforts to introduce web privacy measures that might be det

What prepares men for totalitarian domination in the non-totalitarian world is the fact that loneliness, once a borderline experience usually suffered in certain marginal social conditions like old age, has become an everyday experience …– From The Origins of Totalitarianism (1951) by Hannah Arendt ‘Please write regularly, or otherwise I am going to die out here.’ Hannah Arendt didn’t usually begin letters to her husband this way, but in the spring of 1955 she found herself alone in a ‘wilderness’. After the publication of The Origins of Totalitarianism, she was invited to be a visiting lecturer at the University of California, Berkeley. She didn’t like the intellectual atmosphere. Her colleagues lacked a sense of humour, and the cloud of McCarthyism hung over social life. She was told there would be 30 students in her undergraduate classes: there were 120, in each. She hated being on stage lecturing every day: ‘I simply can’t be exposed to the public five times a week – in other words, never get out of the public eye. I feel as if I have to go around looking for myself.’ The one oasis she found was in a dockworker-turned-philosopher from San Francisco, Eric Hoffer – but she wasn’t sure about him either: she told her friend Karl Jaspers that Hoffer was ‘the best thing this country has to offer’; she told her husband Heinrich Blücher that Hoffer was ‘very charming, but not bright’. Arendt was no stranger to bouts of loneliness. From an early age, she had a keen sense that she was different, an outsider, a pariah, and often preferred to be on her own. Her father died of syphilis when she was seven; she faked all manner of illnesses to avoid going to school as a child so she could stay at home; her first husband left her in Berlin after the burning of the Reichstag; she was stateless for nearly 20 years. But, as Arendt knew, loneliness is a part of the human condition. Everybody feels lonely from time to time. Writing on loneliness often falls into one of two camps: the overindulgent memoir, or the rational medicalisation that treats loneliness as something to be cured. Both approaches leave the reader a bit cold. One wallows in loneliness, while the other tries to do away with it altogether. And this is in part because loneliness is so difficult to communicate. As soon as we begin to talk about loneliness, we transform one of the most deeply felt human experiences into an object of contemplation, and a subject of reason. Language fails to capture loneliness because loneliness is a universal term that applies to a particular experience. Everybody experiences loneliness, but they experience it differently. As a word, ‘loneliness’ is relatively new to the English language. One of the first uses was in William Shakespeare’s tragedy Hamlet, which was written around 1600. Polonius beseeches Ophelia: ‘Read on this book, that show of such an exercise may colour your loneliness.’ (He is counselling her to read from a prayer book, so no one will be suspicious of her being alone – here the connotation is of not being with others rather than any feeling of wishing that she was.) Throughout the 16th century

This post highlights new, simplified and low-/no-cost options for deploying RHEL. These are the first of many new programs. To immediately go to the program that interests you: No-cost RHEL for small production workloads No-cost RHEL for customer development teams On December 8, 2020, Red Hat announced a major change to the enterprise Linux ecosystem: Red Hat will begin shifting our work from CentOS Linux to CentOS Stream on December 31, 2021. We and the CentOS Project governing board believe that CentOS Stream represents the best way to further drive Linux innovation. It will give everyone in the broader ecosystem community, including open source developers, hardware and software creators, individual contributors, and systems administrators, a closer connection to the development of the world’s leading enterprise Linux platform. When we announced our intent to transition to CentOS Stream, we did so with a plan to create new programs to address use cases traditionally served by CentOS Linux. Since then, we have gathered feedback from the broad, diverse, and vocal CentOS Linux user base and the CentOS Project community. Some had specific technical questions about deployment needs and components, while others wondered what their options were for already- or soon-to-be deployed systems. We’ve been listening. We know that CentOS Linux was fulfilling a wide variety of important roles. We made this change because we felt that the Linux development models of the past 10+ years needed to keep pace with the evolving IT world. We recognize the disruption that this has caused for some of you. Making hard choices for the future isn’t new to Red Hat. The introduction of Red Hat Enterprise Linux and the deprecation of Red Hat Linux two decades ago caused similar reactions. Just as in the past, we’re committed to making the RHEL ecosystem work for as broad a community as we can, whether it’s individuals or organizations seeking to run a stable Linux backend; community projects maintaining large CI/Build systems; open source developers looking toward "what’s next;" educational institutions, hardware, and software vendors looking to bundle solutions; or enterprises needing a rock-solid production platform. Today we’re sharing details about some of the new no- and low-cost programs we’re adding to RHEL. These are the first of many new programs. No-cost RHEL for small production workloads While CentOS Linux provided a no-cost Linux distribution, no-cost RHEL also exists today through the Red Hat Developer program. The program’s terms formerly limited its use to single-machine developers. We recognized this was a challenging limitation. We’re addressing this by expanding the terms of the Red Hat Developer program so that the Individual Developer subscription for RHEL can be used in production for up to 16 systems. That’s exactly what it sounds like: for small production use cases, this is no-cost, self-supported RHEL. You need only to sign in with a free Red Hat account (or via single sign-on through GitHub, Twitter, Facebook, and other accounts) to download RHEL and receive updates. Nothing else is required. Th

[Photo by Kelly Sikkema on Unsplash, modified (cropped)] This article follows up on a discussion. Please share your experience there, I'd gladly hear about it! Introduction Some months ago I was surveying a little the state of GUI in Rust. Let me tell you, the quest has been horrible. Starting off some searches on internet, apart some questions on Reddit and other sites, you get some (very old) articles. Sep 19 '19 Author: AwlsomeAlex365 Rust has always seemed super interesting to me since learning of its existence a few months ago. However one thing that turned me off at the time was the lack of (structured) GUI bindings for cross platform devices. But fast forward a few months, is there a good GUI library to use that can make “complex” applications? Or maybe a… Old and stale. The only guide you get at the end of the day (referenced by all) is the site Are We GUI Yet which is not helpful at all. Want to find crates for GUI in Rust? Then you've come to the right place! Status This site is maintained as best as possible. The next steps likely involve replacing it with an automated system more like lib.rs. CI runs weekly to update crate information from crates.io, if it is not overriden by the crate's configuration in this repo. What is this? Companion website to arewegameyet arewewebyet, and arewelearningyet. Contributing To make it easy for people (hey, that's you! 😊) to contribute, AreWeGuiYet uses a custom Rust CLI. It's currently a work in progress and is a little rough around the edges. The workflow: fork AreWeGuiYet clone your fork cd to the CLI directory (cli) (it currently uses relative paths 😬) Build and run the CLI Usage: cargo run -- [--clean] [flags] Help: cargo run -- help When you're done… It seems that AreWeGUIYet has not been updated since 2019, and the interface does not help in the least to search for a suitable library. The only tags it has is on the kind of implementations the crates have. Not many articles, not a useful tutorial, no understanding about the status of the crates that are showcased there. Some featured crates seem pretty rough, some more advanced... but there's no way to know it other than trying each and every one. Oh. My. And I did install some, but the results were a disaster, because at least the ones I tried sucked a lot. Then, over the summer I found an article by boringcactus. They had much my same experience, but I realized that I actually managed to make many more things to work than they did... Flash forward to early November. Here I was, trying again the old way. I was serious with my intention to try each and every crate in the list. This time around I got even luckier. At least I did not only succeeded in make some libraries to work, I actually got material to write some tutorials to help others. Here I'll wet your appetite: there's more to come! Disclaimers I only tried the following on my Linux laptop: sorry, I do not own a Windows or a Mac! I usually employ cargo add from cargo edit (to install it: cargo ins

January 20, 2021 Yesterday, Elastic NV, the company behind Elasticsearch, announced they would release future versions of their Elasticsearch and Kibana software under the Server Side Public License (SSPL) to prevent Amazon from offering them as managed services on its proprietary cloud platform. Elastic joins MongoDB, originator of SSPL, in accusing AWS of unfair play and adopting defensive license terms. The same day, the Open Source Initiative released a short post pointedly entitled “The SSPL Is Not an Open Source License”, attempting to brand Elastic and SSPL “fauxpen source” and generally throwing as many short jabs their way as possible. To hear OSI tell it, Elastic has “abandoned their original dedication to the open source community” by falling prey to the current “license du jour”, announcing the move in a post “unironically titled ‘Doubling Down on Open’”, and hocking what is now a lamentably “proprietary product”. It’s a hit piece. Not that it matters so much. As usual with OSI these days, I don’t think either Elastic or Mongo will feel a thing. The folks at OSI will enjoy “taking a stand”. A few of their faithful will accept the line and shun the offender, mostly by saying mean things on social media somewhere. But Elastic has little to fear from being “called out” by an increasingly fractured and irrelevant institution. It’s one great, big, noisy, cliquish NOP. Or it would be. Alas, there is more in OSI’s post. More bad arguments. More self-serving misinformation. More fear, uncertainty, and doubt in response to anxiety about their self-bestowed “authority”. More seeds of confusion. It is not my responsibility to break the cycle of taunts and jibes between cloud companies, database companies, and their vassals. It’s not my responsibility to “fix” copyleft for the cloud, or to reconcile opposing interests to some kind of amicable, Kumbayah settlement. But as I’ve seen over the years, it will be my responsibility to clean up the mess of misconceptions opportunistically engendered for dubious tactical points along the way. I’d rather not. Retreat? OSI mentions: The [fauxpen source] license du jour is the Server Side Public License. This license was submitted to the Open Source Initiative for approval but later withdrawn by the license steward when it became clear that the license would not be approved. This is literally true. But it begs to leave exactly the wrong impression. Why did MongoDB walk away from the OSI process? Was it because they came to understand, at the foot of OSI’s wisdom, that their license wasn’t open source, but a regrettable heresy? Nope. From the Mongo e-mail OSI links to in quote above: We continue to believe that the SSPL complies with the Open Source Definition and the four essential software freedoms. In other words, they still think it’s open source and free software. Whether OSI, or the people who hang out on OSI mailing lists, say so or not. As I saw it, MongoDB’s exit had everything to do with aborting

Hello Fennel friends! I'm happy to announce the release of version 0.8.0 of Fennel. The highlights for this version are the new "table comprehension" macros `collect` and `icollect`, a completely new serializer in `fennel.view`, and whole-table destructuring using `&as`. For a long time we considered adding things like `map` and `filter` into Fennel, but we decided against it because those are easily brought in by 3rd-party libraries like Lume or Luafun. Fennel has no runtime, so it can only include macros, and traditional map, filter, etc are best done as functions. However, taking inspiration from other languages list comprehensions, `collect` and `icollect` provide similar benefits but in the form of macros which makes them a much better fit for Fennel. No more needing to pull in a 3rd-party library for basic table manipulations. The new Fennelview is completely rewritten in a way that produces much more sensible indentation. The previous logic for indentation was very haphazard and driven by implementation details, now it follows lisp conventions. But even better is that it allows you to override the printing behavior with a `__fennelview` metamethod, and allows your output to get indented in a way that fits nicely with the context. And then the whole-table destructuring solves a long running problem of wanting to destructure a table but keep a reference around to the original. Previously you would have had to do this as two separate bindings; one for the destructuring and one for all: (let [{:a a :b b &as all} {:a 1 :b 2 :c 3 :d 4}] (+ a b all.c all.d)) ; => 10 The full list of user-visible changes: * Allow the parser to optionally include comments in the parsed AST * The fennelview module is now incorporated into the compiler as `fennel.view` * Fully rewrite fennelview for better indentation handling; see fennelview docstring for detailed description of API changes * Improve printing of destructured args in function arglist in `doc` * Allow plugins to provide repl commands * Fix a bug where decimal numbers would be emitted with commas in some locales * Label auto-generated locals in Lua output for improved readability * Fix the behavior of `...` inside `eval-compiler` * Warn when using the `&` character in identifiers; will be disallowed later * Add whole-table destructuring with `&as` * Add list/table "comprehension" macros (`collect`/`icollect`) * Numbers using underscores for readability **may not** begin with an underscore * Provide `...` arguments consistently with Lua when requiring modules * Fix a bug where `import-macros` would not respect certain compiler options * fennelview: respect presence of `__fennelview` metamethod on userdata metatables * Fix a bug where shebang caused incorrect sourcemapped row/col in stacktraces Thanks to everyone who contributed to this release; in particular Thomas Berryhill for the table comprehensions and Andrey Orst for the new Fennelview. You can download the latest version here: https://fennel-lang.org/downloads/fennel-0.8.0 https://fennel-lang.org/downloads/fennel-0.8.0.asc I think now we are not far off from a 1.0.0 release! Please let us know if you

I thank Daniele F. for donating this terminal. He contacted me from the donation page at the end of May but I couldn’t retrieve it until the beginning of October, when I passed through Verona while I was going to Brusaporto (a few kilometres from Bergamo) where I attended an annual retrocomputing meeting. The terminal, after a thorough cleaning and an accurate inspection, turned on without any problems. It was just dusty and dirty. The first item I started to clean was the keyboard. The next picture shows it before and after the cleaning process. I know that I’ve said it before… detaching and cleaning every single key is boring. But it is a manual and repetitive task that frees my mind, I find it quite relaxing, and the final result is always worth the time spent. Look at the next photo: beautiful, clean, shiny keys, with that mechanical feeling I sometimes miss on modern keyboards. Here’s the keyboard board without the keys, after being cleaned: The next picture shows the detail of the key. There was no need for a “keycap puller”, the keys came off easily – so easily that I was lucky that no key was lost in all these years. This image is taken from the technical manual I found on the net. After the keyboard I cleaned the main unit. The “Lunar” badge was probably added by the seller or the distributor, but I couldn’t find any information about it. Under the badge you can see the original colour of the case. If you look closely, you can see that the CRT monitor has a ghost image caused by showing the same static text many hours a day for years. Here’s the teardown picture. There’s a sticker under the keyboard, used to keep track of the terminal settings. In the setup screen that you can see in the first picture there are 4 series of 4 bits: each one sets an option, explained in the manual and summed up on the sticker. The unit was designed with easy reparability in mind. The top and bottom case are kept together with just four clips; a few other clips keep the main unit attached to the bottom case. The motherboard and the graphic board can be pulled out by unscrewing a panel on the back. The power supply unit can be pulled from the main by lifting – you’ve already guessed – some clips. The power supply unit: The main processor is an Intel 8080. The Selanar Graphics 100 is an additional third party board that lets the terminal show 132 columns on screen and use advanced character formatting. It’s based on an Intel 8085 processor. The side view of the terminal: You can immediately recognize the VT100 on the manual cover: The most useful site I found about the VT100 is VT100.net; you can find the technical manual on the Internet Archive. The only information about the Selanar Graphics 100 came from a Google Book scan of Computerword magazine from August 1980. It cost $1195, and on the same page there’s an ad for the VT100 at $1550. That makes a total of $2745, that according to usinflationcalculator.com corresponds to $7926 in 2015. For a terminal!