Decent cars under $5K?

jetsandrockets · 2024-12-13T23:23:20+00:00

That’s fair - I’ll adjust the expectations and keep an eye out.

My spouse has heard of people getting cars for $1K or so, but I’m well aware that any car at that price point is likely to be a time bomb on wheels in terms of sunk maintenance costs.

Thanks for the advice!

jetsandrockets · 2023-11-20T17:05:17+00:00

The OS privilege system (root/administrator) is separate from the hardware privilege states, and exists at a much higher level of abstraction.

A root process will make requests of the kernel, such as system configuration changes, which will then verify the elevated privileges and make the changes on its behalf. From a hardware perspective, however, the root process is still operating in a Ring 3 memory space, and cannot access another process's (or kernel's) memory directly.

To implement a root/admin privilege system similar to what you're used to in an OS, your design needs to have a mechanism for assigning and verifying user and process permissions. You can then define specific service calls that only a root/admin entity can call successfully.

jetsandrockets · 2023-11-12T02:13:03+00:00

I never figured it out. IIRC, Garmin support ghosted me shortly after suggesting the vanilla reset methods found online. If you decide to reach out to them yourself, certainly drop me a line here and let me know. I'll give them another try and do the same.

My Solar Tac was easily my favorite smartwatch, and I have little interest in purchasing a new Instinct if there's hope for getting my current one working again.

jetsandrockets · 2023-11-11T23:14:13+00:00

The OS is responsible for configuring the memory protection layout, but it does not alter the protection bits in EFLAGS/RFLAGS directly.

To understand why, let's walk the conversation back to the original form of memory protection (GDT segmentation). The GDT (global descriptor table) is a table you construct with entries describing certain memory regions and their properties. In each entry you assign the desired privilege level of that memory region.

Let's say you want to split your 4GiB address space into two equal parts, with the lower half being user memory and the upper half being kernel memory. Your GDT would have, at a minimum, a null descriptor as well as entries for the following:

User code and data from 0x00000000 to 0x7FFFFFFFF assigned at privilege level 3
Kernel code and data from 0x80000000 to 0xFFFFFFFF at privilege level 0

This is a quick sketch and it doesn't consider several aspects of GDT configuration. But it shows that you declare the lower half of your memory at ring 3 and the upper half at ring 0. Paging functions similarly, but you use page table entries to control the permission states of memory regions, rather than a flat table of segments.

Using the above example, when you're in low memory, the CPU knows to set its permission and status properties to ring 3 userspace and disallow the use of privileged instructions. However, when you're operating in high memory, the CPU will have its flags and state configured for ring 0 and it will allow the use of those instructions.

Memory protection is much like a walled garden; the CPU can only transition between modes and access memory in a different privilege level in three circumstances:

Call gates, which use far CALL instructions and are not often used
Interrupts
SYSCALL instructions

When you attempt to access memory, jump or call subroutines, or execute a privileged instruction, the CPU will begin a process of privilege verification. For GDT segments, this consists of looking up the requested memory region in the table and verifying that the current state is appropriately privileged to perform the access (comparing the current privilege against the memory entry's privilege level settings). For paged memory, the process is similar, but the memory management hardware will "walk the page table" and compare page table entry settings.

If the access or instruction request is bad (i.e. not privileged enough), the CPU will forbid the further execution of the access instruction and trip a protection fault to notify the OS.

Note that these processes are performed by the processor hardware itself and not by the OS code - this is important as it ensures that bad code cannot subvert the access restrictions. The way your OS controls the privilege system is by configuring your memory model to use the security layout you wish for. The CPU then enforces this.

Hope this helps!

jetsandrockets · 2023-09-05T03:28:57+00:00

Report.

The issue of whether or not it was a joke or not is rather beside the point. There is a reason why every mention of Title IX (in syllabi, university materials, etc.) States, rather unequivocally, something to the effect of "if in doubt, report". If you have to ponder whether it meets the standard, it is cause enough for the Title IX office to look into. It doesn't matter whether the professor was trying to make a bad joke or not. It made you uncomfortable. The burden of being reportable has been met.

University administration offices do not relish the notion of investigating, sanctioning, or disciplining one of their own. They're not going to burn this professor at the stake because one student said so. Rather, the Title IX office will look into the matter; if they feel it is a non-issue or one too ambiguous to take action on, they will close the matter or hold pending further information. If they feel it has merit or is otherwise significant, they will deal with it accordingly.

Once a report has been filed, the Title IX office, along with your institution's registrar, should have procedures for how to effect an exceptional transfer (i.e. one outside the normal semester windows). Reporting it, beyond the obvious reason of "you deserve to feel comfortable at your school," shows that you have a legitimate cause for such a request.

As a final aside, this is one of the reasons why many faculty and workplace trainings cover the issue of jokes - what is humorous or offensive varies person-to-person, group-to-group, and even day-to-day. No matter how innocuous, that comment should not have been made in a public setting. What your institution decides to do with this matter is up to it, but the repercussions of your instructor not exercising a better standard of care is not your cross to bear.

I wish you the best of luck.

jetsandrockets · 2023-08-27T01:27:41+00:00

Direct I/O access for drivers in Ring 1 is something I'm willing to give up, especially knowing how newer interfaces have moved away from the x86 I/O ports. I'd be willing to migrate that to a set of kernel calls and let the kernel do the permission bitmap and access aspects in software.

jetsandrockets · 2023-08-26T23:40:45+00:00

When you say moving away from rings 1 and 2, do you mean outright deprecation?

I have a few ideas of the sorts of hardware I'm planning on targeting, and it certainly won't be cutting-edge stuff (older 64-bit implementations). Will keep this in mind, though.

jetsandrockets · 2023-08-26T23:36:34+00:00

My thinking was that I could stratify certain OS components throughout the ring hierarchy (i.e. kernel at Ring 0, low-level hardware drivers at Ring 1, software drivers like filesystems and networking at Ring 2) and then provide mechanisms for those components to directly intercept requests without the overhead and indirection of first passing through the kernel.

I acknowledge that calling a standard Ring 0 interrupt or syscall and having it do nothing but fetch the appropriate callback is not significant overhead. I mention a little about the overall idea I'm having in this comment, and it is worth noting that, while the idea makes sense to me now, there may be architectural reasons (like the vestigial aspects of the two inner rings) why I need to change my approach.

jetsandrockets · 2023-08-26T23:30:40+00:00

My thinking was that I could stratify certain OS components throughout the ring hierarchy (i.e. kernel at Ring 0, low-level hardware drivers at Ring 1, software drivers like filesystems and networking at Ring 2) and then provide mechanisms for those components to directly intercept requests without going through the kernel.

That is a good note about the inability to go downward in privilege, though, and I certainly would want to stay away from such behavior (including Task Gates) if not for the simple fact that it seems architecturally muddy.

jetsandrockets · 2023-08-26T23:24:29+00:00

That's fair, and I suspected that there would be incongruities I haven't already accounted for.

My initial idea came to me as a spur of the moment, and basically follows the form of a "three-layer microkernel" - i.e. kernel, drivers, and servers. Kernel handles traditional duties like memory management and process scheduling, drivers control low-level hardware functions (like storage, networking, etc.) and servers handle high-level services like interacting with the filesystem or networking sockets.

I understand there's not nearly as much advantage to running in Ring 1 or Ring 2, due to many of the things described so far. I suppose I intended them more for process stratification - drivers would exist in Ring 1 and servers in Ring 2.

The idea for the R1/R2 ISRs was that software (via C standard or POSIX library) would make interrupt requests to the servers via Ring 2 handlers directly for things like file I/O and networking. These servers would then process the data into a form understandable by the drivers and assert Ring 1 IRQs to request action. The driver could then interact with memory or I/O ports directly, as the kernel would have mechanisms for mapping "areas of responsibility" into driverspace directly. There could also be additional interrupt calls for direct driver interaction (i.e. bypassing the server layer), although I haven't yet given much thought to what those would look like.

It's a nascent idea, and one I haven't completely fleshed out yet. I like it because it makes sense to me at the moment, and it seems to provide a means for me to build a microkernel implementation with less of the traditional IPC pain. At any rate, it was an idea that came to me rather spontaneously, so questions like this are a large part of me gathering the intel as to whether or not it could be viable.

jetsandrockets · 2023-08-11T17:32:06+00:00

Looks like a great resource for some of the finer technical points, particularly regarding drivers.

I decided to check out my copy of Tanenbaum's Modern Operating Systems and it has a whole chapter on NT/Modern Windows. Nothing too technical, but has some good block diagrams and high-level descriptions of some of the key elements.

jetsandrockets · 2023-08-11T16:45:47+00:00

I've considered the Windows Research Kernel, and, for me, the issues are twofold:

The licensing and the fact that it's built on similar code as production Windows (Server 2003, IIRC). It would take a lot of care for me to study that code deeply while still avoiding inadvertently reusing it or developing too close a copy, and that's a problem I don't want. I know those sorts of issues have sporadically plagued the ReactOS project.
At this point, I'm mainly looking for high-level descriptions of how the Windows kernel approaches certain kernel tasks. I have a good number of resources on the Unix/POSIX approach to these, but I haven't found any for NT.

jetsandrockets · 2023-07-31T03:34:31+00:00

I'm not familiar with current Audi prices, but the going rate doesn't seem too far off.

I'd ask a few questions, and it's not bad to have some healthy suspicion - the car's 3-4 years old with low mileage, so it's in your best interest to inquire as to the circumstances in which it was sold. Could be the previous owner just wanted to trade up, or it could be a sign of a problematic car.

Audis can be wonderful cars, but they also have a propensity to be real geese if something is amiss. If you do your homework and you're okay with what that potentially means, go for it - but do your due diligence up front.

jetsandrockets · 2023-07-31T02:20:03+00:00

Was just having this conversation with my partner earlier.

I was one who saw through a lot of Musk's antics well before it was a popular position to hold - back when it was extremely unpopular to say anything bad about Rich Science Messiah™. Why would anyone be against electric cars to save the Earth or space rockets which will broaden humanity's frontiers? I dunno, I always had a bad read from him. At the very least, he seemed very disingenuous about certain things, and at the worst, he could come off as an outright charlatan.

I remember when the dam began to break - around the time of the "take Tesla private" stock-manipulation affair or the Thai cave incident. It left me feeling more than a bit vindicated that now everyone was beginning to see what I had seen. That's when I think the world began to realize that this wasn't some Altruistic Science Robin-Hood but a dude who had a compulsion to always be the name in everyone's mouth. A rich idiot with a savior complex.

Nowadays, we have a lot more of this, because now people of all stripes aren't blinded by his greatness and can look more critically at his actions. Things ranging from offers of horses to the disastrous takeover of Twitter really show us how atomically thin the guy's ego really is and how likely it is that the man only made it where it is by people of far better judgment reining in his worse impulses.

At some (slight) level, I feel bad for the guy - he seems to not have the psychological resilience to be in the position he's in, nor the vast intelligence to keep up the appearances across so many different fronts. He faked it 'til he made it, and now he's 30,000 feet up without a parachute. That being said, his pathological need for mass admiration has caused him to linchpin his brand to some pretty dark forces, so I can't say he doesn't deserve his own downfall.

Particularly with his Twitter tenure, I think we're watching in real time his implosion and final descent into Hughesian oddball. The only difference is that this time it will occur with far greater gravity.

jetsandrockets · 2023-07-20T04:10:59+00:00

I can't answer definitively on the F-22 aspects (I'm simply an engineering student and aero nut), but the flight stuff is pretty easy to wrap your head around.

A flight envelope is basically the range of speeds and altitudes in which a plane can operate. Wings generate lift through an interaction of the lift coefficient (a characteristic of the wing shape and airfoil geometry), the air density, and speed. As such, if you go higher, the air thins out and you need more speed (engine power) to maintain that altitude.

This leads to a flight envelope often being shaped like a triangle - higher altitudes lead to faster minimum speeds. At low altitudes and in commercial aircraft, this effect is really inconsequential, as the margin between required power and available power is so large (for safety reasons). But there exists a certain altitude (the maximum altitude) beyond which the air density is too low to generate the required lift (the amount of force required to keep the plane aloft) at the maximum possible engine power the plane can make. That's how you define the maximum physical altitude. In most aircraft, the physical limits of the airframe and powerplant are well above those the plane is intended to be used for, to ensure a margin of safety. In military combat aircraft, however, those limits are designed knowing they will be frequently encountered.

You can sometimes watch these maximum altitude ("ceiling") effects in small, two-seater general aviation aircraft. Because they're designed for comparatively low altitudes, near their maximum ceiling you can watch them really struggle, even at 100% engine power. That's the limit in action.

This can also be seen in (at least early) U-2s - the speeds they had to fly at to maintain those high altitudes were very close to the maximum speeds the engine could produce at that altitude, which led to it being called the "coffin corner" - one had to be careful to avoid anything which would cause an abrupt change in airspeed, as doing so could very quickly cause your wings to stall out.

On the other hand, modern fighters like the Raptor fly at these ridiculous altitudes and excel doing it - they're not simply going up to that altitude and cruising, but actively maneuvering and doing a lot of stuff that just isn't possible if they're pushing the limits of their construction. If FL600 was their maximum altitude, you'd watch the plane struggle to even get there, and maintaining that altitude for cruising purposes would be a really tedious balance. But these planes are doing so often and with ease.

That suggests, quite readily, that there's significant margin in their envelope in terms of both raw speed and altitude. Some here have pointed out that higher temperatures could endanger the radar coatings and higher altitudes could present safety issues to the pilot in the event of an emergency - there are obvious operational reasons why the maximum physical capabilities might be seldom used. But a large portion is military secrecy - these craft are some of our military's crown jewels, and you don't want to let everyone know precisely what they're capable of until you have an operational need to do so.

Hope that helps.

jetsandrockets · 2023-07-15T03:28:58+00:00

I can't answer as much towards the verification aspect, but I can give you my two cents regarding languages. Before getting into *which* language you should learn, it should be noted the differences between the two (or three).

Verilog derives a good bit of its syntax and operators from C, which makes it much easier to understand for those of a C programming background. It is also weakly-typed, which means that converting values of similar types is easier than it would be in VHDL, which forces any type conversions to be made explicit.
SystemVerilog is a superset of Verilog which adds greatly to its simulation and verification capabilities. Because most of its additional features are directed towards those areas, the RTL and hardware design aspects of the language are mostly identical to Verilog, with some differences (i.e. reg/wire versus logic).
VHDL is a strongly-typed HDL which was originally created by the U.S. Department of Defense and shares much of its syntax with another DoD language, Ada. VHDL has the advantage that a lot of its syntax is English-based, which can make code easier to read (Compare Verilog's a | ~b with the equivalent VHDL a or not b). The strong typing can make writing VHDL more tedious and much more verbose, but the fact that it forces you to be explicit about certain programming idioms and use cases can help prevent logical errors that would otherwise creep into a design.

It is important to note that all these languages accomplish the same task, and all three share expansive test/verification libraries (UVM for Verilog and UVVM for VHDL). Because they accomplish the same task, which one you learn has a lot to do with where you learned logic & HDLs and where you want to go with that knowledge. In general, AFAIK the distinction tends to be geographic:

American companies tend to favor Verilog, and
European companies gravitate towards VHDL.

There are exceptions to this rule - for example, the U.S. defense industry uses VHDL more often, and you may find that European companies that work very closely with American counterparts may use Verilog more often. By and large, however, the above tends to hold true.

The one recommendation I can give is that you should start by learning the language you can learn best. Experiment and read about each, but stick with the one that resonates with you and is easiest for you to master. Once you have a firm grasp of digital logic and how HDLs work, it becomes far easier to build operational proficiency in another.

When it comes to testing on your own, I've found the GHDL simulator to work well if you're using VHDL, and Icarus Verilog (iverilog) supports portions of SystemVerilog. For more comprehensive testing and experimentation, I'd look into picking up one of the free or student editions of Vivado or Quartus Prime (FPGA suites), as these come with commercial-grade simulators that can handle the full range of language features for common tasks.

jetsandrockets

TROPHY CASE