413 private links
Thursday 2nd April 2020 15:11 GMT
BJC
Millisecond roll-over?
So, what is the probability that the timing for these events is stored as milliseconds in a 32 bit structure?
Reply Icon
Re: Millisecond roll-over?
My first thought too, but that rolls over after 49.7 days.
Still, they could have it wrong again.
Re: Millisecond roll-over?
I suspect that it is a millisecond roll over and someone at the FAA picked 51 days instead of 49.7 because they don't understand software any better than Boeing.
Thursday 2nd April 2020 17:05 GMT
the spectacularly refined chap
Reply Icon
Re: Millisecond roll-over?
Could well be something like that, the earlier 248 day issue is exactly the same duration that older Unix hands will recognise as the 'lbolt issue': a variable holding the number of clock ticks since boot overflows a signed 32 bit int after 248 days assuming clock ticks are at 100Hz as was usual back then and is still quite common.
See e.g. here. The issue has been known about and the mitigation well documented for at least 30 years. Makes you wonder about the monkeys they have coding this stuff. //
bombastic bobSilver badge
Reply Icon
Devil
Re: Millisecond roll-over?
I've run into that problem (32-bit millisecond timer rollover issues) with microcontrollers, solved by doing the math correctly
capturing the tick count
if((uint32_t)(Ticker() - last_time) >= some_interval)
and
last_time=Ticker(); // for when it crosses the threshold
[ alternately last_time += some_interval when you want it to be more accurate ]
using a rollover time
if((int32_t)(Ticker() - schedule_time) >= 0)
and
schedule_time += schedule_interval (for when it crosses the threshold)
(this is how Linux kernel does its scheduled events, internally, as I recall, except it compares to jiffies which are 1/100 of a second if I remember correctly)
(examples in C of course, the programming lingo of choice the gods!)
do the math like this, should work as long as you use uint32_t data types for the 'Ticker()' function and for the 'scheduld_time'; or 'last_time' vars.
If you are an IDIOT and don't do unsigned comparisons "similar to what I just demonstrated", you can predict uptime-related problems at about... 49.71 days [assuming milliseconds].
I think i remember a 'millis()' or similarly named function in VxWorks. It's been over a decade since I've worked with it though. VxWorks itself was pretty robust back then, used in a lot of routers and other devices that "stay on all the time". So its track record is pretty good.
So the most likely scenario is what you suggested - a millisecond timer rolling over (with a 32-bit var storing info) and causing bogus data to accumulate after 49.71 days, which doesn't (for some reason) TRULY manifest itself until about 51 days...
Anyway, good catch.
Re: Yes and no
OK, here's the situation.
you fork an upstream repo, your fork is private
you commit something there that should not see daylight (keys to the Lamborghini or whatever)
you delete that commit to hide your sins
and now that commit is apparently still easily accessible from upstream. //
Re: Yes and no
Also - as far as I can see it's not actually possible to create private native GitHub forks of public repos in GitHub
The example they cite is when you have a private repo that will eventually become public, fork it to make permanently-private fork and then later make the original repo public. Anything commited to the still-private repo up until the point the first repo is made public, can be accessed from the now-public repo. (As long as you know the commit hashes, that is - but unfortunately they're easily discoverable.) //
The issue is that people are mentally modelling forks as "that's my copy of the repo, completely separate from the original" whereas in reality the fork is just a different interface to the same pool of blobs. Furthermore, while you wouldn't be able to access commits from another fork in the same pool of blobs unless you know the commit hash, github makes those commit hashes discoverable. //
Re: Yes and no
For the people downvoting me - you are aware how quickly AWS credentials accidentally exposed on GitHub are found and abused by attackers? Honeypot tests suggest 1 minute.
https://www.comparitech.com/blog/information-security/github-honeypot/
Note that at no point in the "what to do if you've exposed credentials" section does it say "delete the public repo in the hope that this will alter the past". Magical thinking.
Having played around with this on GitHub, I will say that the message on trying to delete a repo isn't explicit enough about the unexpected (if documented) behaviour. It really ought to have a disclaimer that says "If you're trying to delete commits you wish you hadn't pushed everywhere, this won't achieve it", and a link to a page describing what will actually help. //
What happens in Repo Stays In Repo
"It's reasonable to expect that deleting a commit tree that nobody else has yet accessed will prevent it from being accessed in future."
No it isn't. It's supposed to be a history. In a code repo, the ability to permanently delete past changeset data should be considered a bug or design flaw. The inability to lose history is the whole point.
Source code has no right to be forgotten, when it's in an SCM, because the point of the SCM is to remember.
Bebu Silver badge
Windows
I am not too sure...
about the "immortality" of FOSS code.
Looking at the C code in Lions Unix (v6) commentary the code is pretty rough by any standard and certainly when compared with contemporary Linux and BSD code. I imagine in 50 years time that code will look peculiar too.
Long ago having ported quite a lot of open source code between System V and BSD systems (and from VAX/VMS) I can say a lot of it was pretty ghastly and could only be immortal in the sense of a vampire or zombie.
Scientific and Engineering Fortran code, mostly numerical analysis or numerical algorithms does seem immortal. I have had to deal with 40+ year old fortran source which with a bit of compiler tweaking and a couple of (automated) edits compiled cleanly and passed its test suite.
Whether Rust, Go etc etc are still in extended use in 20 years time is probably 10:1 against.
PL/1, Simula67, and even Ada while not gone aren't exactly in common use.
Human perversity will probably ensure people are still hacking away in ISO C42 and using -std=c89 to retain K&R function definitions.
I suppose I could reimplement coreutils in SPARK (Ada). ;)
What is a Version 1 UUID?
A Version 1 UUID is a universally unique identifier that is generated using a timestamp and the MAC address of the computer on which it was generated.
Do you use tabs or spaces for code indentation?
This is a bit of a "holy war" among software developers; one that's been the subject of many debates and in-jokes. I use spaces, but I never thought it was particularly important. But today we're releasing the raw data behind the Stack Overflow 2017 Developer Survey, and some analysis suggests this choice matters more than I expected.
Spaces make more money than tabs
One does not simply suggest changing a kernel line to help out a parsing tool. //
Cloudgazer Ars Tribunus Angusticlavius
9y
17,106
Syntactic sugar causes cancer of the semi-colon - Alan Perlis. //
DJ Farkus Ars Centurion
3y
368
Tabs or spaces: flexible, don't care.
Tabs of 2, 4, 8, whatever: flexible, don't care
But ask me to use a language where whitespace is syntax (eg, python) and we will have sharp words.
Responsive and adaptive
PHP Generator for MySQL allows you to create applications that look fine on any device from a mobile phone to an extralarge desktop.
Connecting a MySQL database with a PHP website can be challenging, especially for beginners. Developers must ensure they have the correct credentials and that the connection is properly configured.
After the connection is set up, developers may encounter errors when retrieving or manipulating data from the database. Debugging these errors can be time-consuming. Security is also a major concern to prevent unauthorized access to sensitive data.
In this tutorial, we'll build a RESTful CRUD application with PHP & MySQL in the backend and Vue.js in the frontend. We'll also be using Axios for sending Ajax request to PHP from Vue.
The Vue.js library, Axios client and Ajax technology allows you to fetch and display data in your application without the need to refresh the whole page each time.
DaDaBIK is a no-code / low-code development platform that can be used to quickly develop any type of data-driven application without coding.
Instead of writing your application using a programming language (such as PHP, Python or Java) you can build the application using a "point and click" approach, even if you don't have any coding skill (that's why no-code): starting from a database (MySQL, PostgreSQL, SQLite or Microsoft SQL Server) or from an Excel file you can generate a basic Web data-entry application in minutes and then customize it with very little effort.
Laravel is a web application framework with expressive, elegant syntax. We’ve already laid the foundation — freeing you to create without sweating the small things.
The outage highlights how extensive people's reliance on technology has become and how an error based on something as trivial as a calendar date can upturn entire businesses and disrupt people's day. While some gas stations were still able to accept other forms of payments, those that relied on the broken terminals found themselves missing out on business. RNZ reported speaking to someone who was declined service by four gas stations due to the outage. //
Z1ggy Ars Legatus Legionis
14y
15,264
fahirsch said:
Well, it's just a one day problem that won't repeat until 2028😃
So if i know how bugs get fixed, it wont get fixed until 2/29/2028.
This is a compiled list of falsehoods programmers tend to believe about working with time.
Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.
The programming language Pascal has become the dominant language of instruction in computer science education. It has also strongly influenced languages developed subsequently, in particular Ada.
Pascal was originally intended primarily as a teaching language, but it has been more and more often recommended as a language for serious programming as well, for example, for system programming tasks and even operating systems.
Pascal, at least in its standard form, is just plain not suitable for serious programming. This paper discusses my personal discovery of some of the reasons why.
Picat is a research language intended to combine logic programming, imperative programming, and constraint solving. I originally learned it to help with vacation scheduling but soon discovered its planner module, which is one of the most fascinating programming models I’ve ever seen.
First, a brief explanation of logic programming (LP). In imperative and functional programming, we take inputs and write algorithms that produce outputs. In LP and constraint solving, we instead provide a set of equations and find assignments that satisfy those relationships.
Best practices for manipulating data with Pandas. This book will arm you with years of knowledge and experience that are condensed into an easy to follow format. Rather than taking months reading blogs and websites and searching mailing lists and groups, this book will teach you how to write good Pandas code.
Patterns for Data Manipulation
Manipulate your data with ease.
Master predictable patterns to clean, visualize, prepare, pivot, summarize, and predict data. Write code that is easy to use, debug, come back to a week later, and put into production. Stop worrying about if you will be able to use your Jupyter notebook when you come back tomorrow.
Learn how to quickly and reliable load, clean, and prepare data. Think about data processing like a "recipe".
Meet Spaghettify
A Visual Studio Code extension to make your code spaghetti. 🍝
Evangelist of lean software and devisor of 9 programming languages and an OS was 89 //
In his work, the languages and tools he created, in his eloquent plea for smaller, more efficient software – even in the projects from which he quit – his influence on the computer industry has been almost beyond measure. The modern software industry has signally failed to learn from him. Although he has left us, his work still has much more to teach.
The C programming language was devised in the early 1970s as a system implementation language for the nascent Unix operating system. Derived from the typeless language BCPL, it evolved a type structure; created on a tiny machine as a tool to improve a meager programming environment, it has become one of the dominant languages of today. This paper studies its evolution.
IBM found themselves in a similar predicament in the 1970s after working on a type of mainframe computer made to be a phone switch. Eventually the phone switch was abandoned in favor of a general-purpose processor but not before they stumbled onto the RISC processor which eventually became the IBM 801. //
They found that by eliminating all but a few instructions and running those without a microcode layer, the processor performance gains were much more than they would have expected at up to three times as fast for comparable hardware. //
stormwyrm says:
January 1, 2024 at 1:56 am
Oddball special-purpose instructions like that are not what makes an architecture CISC though.
Special-purpose instructions are not what makes an architecture RISC or CISC. In all cases these weird instructions operate only on registers and likely take only one processor bus cycle to execute. Contrast this with the MOVSD instruction on x86 that moves data pointed to the ESI register to the address in the EDI register and increments these registers to point to the next dword. Three bus cycles at least, one for instruction fetch, one to load data at the address of ESI, and another to store a copy of the data to the address at EDI. This is what is meant by “complex” in CISC. RISC processors in contrast have to have dedicated instructions that do load and store only so that the majority of instructions run on only one bus cycle. //
Nicholas Sargeant says:
January 1, 2024 at 4:00 am
Stormwyrm has it correct. When we started with RISC, the main benefit was that we knew how much data to pre-fetch into the pipeline – how wide an instruction was, how long the operands were – so the speed demons could operate at full memory bus capacity. The perceived problem with the brainiac CISC instruction sets was that you had to fetch the first part of the instruction to work what the operands were, how long they were and where to collect them from. Many ckock cycles would pass by to run a single instruction. RISC engines could execute any instruction in one clock cycle. So, the so-called speed demons could out-pace brainiacs, even if you had to occasionally assemble a sequence of RISC instructions to do the same as one CISC. Since it wasn’t humans working out the optimal string of RISC instructions, but a compiler, who would it trouble if reading assembler for RISC made so much less sense than reading CISC assembler?
Now, what we failed to comprehend was that CISC engines would get so fast that they could execute a complex instruction in the same, single external clock cycle – when supported by pre-fetch, heavy pipelining, out-of-order execution, branch target caching, register renaming, broadside cache loading and multiple redundant execution units. The only way that RISC could have outpaced CISC was to run massively parallel execution units in parallel (since they individually would be much simpler and more compact on the silicon). However, parallel execution was too hard for most compilers to exploit in the general case.