PCB business cards for electronics engineers might be very much old news in our circles, but they are still cool, not seen too much in the wild, and frankly inaccessible to those in other industries. For their entry into the 2024 Business Card Challenge, [Dima Shlenkevitch] is helping a little to alleviate this by providing a set of design examples and worked costs with suppliers.
Original green is still the cheapest option.
[Dima] lists key features every PCB business card should include, such as the expected thickness, restrictions for placing NFC components, and some aesthetics tips. Make sure to choose a supplier that allows you to remove their order number from the manufactured PCB, or it will look out of place.

Ordering PCBs with these specifications to keep costs reasonable requires effort, so [Dima] offers some example designs along with the results. If you want to have pretty gold lettering and graphics, you will need ENiG plating, increasing the price. Non-standard solder mask colors can also raise the price.

Will this help with the practical aspects of driving the PCB design software and actually placing the order? Obviously not, but the information provided gives you a leg up on some of the decisions so you don’t go down an expensive rabbit hole.

By the time you read this the Iowa-class battleship USS New Jersey (BB-62) should be making its way along the Delaware River, heading back to its permanent mooring on the Camden waterfront after undergoing a twelve week maintenance and repair period at the nearby Philadelphia Navy Yard.

The 888 foot (270 meter) long ship won’t be running under its own power, but even under tow, it’s not often that you get to see one of the world’s last remaining battleships on the move. The New Jersey’s return home will be a day of celebration, with onlookers lining the banks of the Delaware, news helicopters in the air, and dignitaries and veterans waiting eagerly to greet her as she slides up to the pier.

But when I got the opportunity to tour the New Jersey a couple weeks ago and get a first-hand look at the incredible preservation work being done on this historic ship, it was a very different scene. There was plenty of activity within the cavernous Dry Dock #3 at the Navy Yard, the very same slip where the ship’s construction was completed back in 1942, but little fanfare. Staff from North Atlantic Ship Repair, the company that now operates the facility, were laboring feverishly over the weekend to get the ship ready.

While by no means an exhaustive account of the work that was done on the ship during its time in Dry Dock #3, this article will highlight some of the more interesting projects that were undertaken while it was out of the water. After seeing the thought and effort put into every aspect of the ship’s preservation by curator Ryan Szimanski and his team, there’s no doubt that not only is the USS New Jersey in exceptionally capable hands, but that it will continue to proudly serve as a museum and memorial for decades to come.

A Fresh Coat of Paint

The primary goal of putting New Jersey into dry dock was to repaint the hull below the water line, something which had not been done since the ship was deactivated by the US Navy in 1990. Under normal circumstances this is the sort of routine maintenance that would be done every few years, but for a static museum ship, the recommended dry docking interval is 30 years. There was no indication that the hull was in particularly bad shape or in need of emergency repair — most of the work done during this yard period was preventative in nature.

The first step in this process was to remove the old paint, along with any biological growth and rust. Unfortunately, there’s no “easy” way to do this. The entire surface area of the underwater hull, totaling roughly 125,000 square feet (11,600 square meters), was painstakingly cleaned using ultra-high pressure washers operating at approximately 30,000 psi. In some areas, getting close enough to the surface of the hull meant putting workers up on a lift, but for the ship’s relatively flat bottom, personnel had to squat down and spray the surface over their heads.

As the ship is resting on around 300 “keel blocks”, this process had to be done in two separate phases. First, the approximately 90% of the hull that was not covered by the blocks was stripped, painted, and left to dry. Then the dry dock was flooded just enough to get the ship floating , so it could be pulled forward a few feet and dropped back down to uncover the areas of the hull that were previously covered.

Checking for Leaks

Even though the steel of the hull itself might be intact, a large ship will have many openings under the water line that can leak if not properly maintained. According to Ryan the New Jersey has about 165 such openings, ranging from tiny drain lines to massive seawater intakes. While the ship was in operation each one of them would have served an important purpose, but as a floating museum with essentially no operating hardware onboard, they’re a liability.

The easiest solution would have been to simply weld plates over all of them. But part of the arrangement that allows the New Jersey to operate as a museum is that the Navy has the right to take the ship back and reactivate it at any time. Admittedly it’s an unlikely prospect, but those are the rules.

Permanently blocking up all those critical openings would make the ship’s reactivation that much more difficult, so instead, each one was “boxed over” with a custom-made steel enclosure. The idea is that, should the ship ever need to return to operation, these boxes could easily be cut off without damaging the hull.

Only one of these boxes was known to be leaking before pulling New Jersey out of the water, but out of an abundance of caution, the integrity of each one was manually checked by pressurizing them with air. If the box held pressure, it was good to go. If it lost air, then it was sprayed with soapy water and closely inspected for bubbles. If there were no bubbles on the outside that meant the air was leaking into the ship through whatever the enclosed fitting was — a problem the Navy might need to address in World War Three, but not something the museum needed to concern themselves with.

Swapping Out Anodes

To help fight off corrosion ships use a technique known as cathodic protection, which essentially turns the steel of the hull into the cathode of a electrochemical cell. The surrounding water serves as the electrolyte, and blocks made of a metal with a high ionization tendency are mounted to the ship to act as the anode. As electrons flow through this circuit, the sacrificial anode dissolves, sparing the hull and other underwater gear such as the propellers.

New Jersey was fitted with 1,200 anodes when the Navy deactivated her, but unfortunately, they ended up being the wrong type. At the time it was assumed that the ship would be stored in a saltwater port as part of what’s known as the “Mothball Fleet”, so zinc anodes were used. There was no way to know that, a decade later, the ship would be transferred to the fresh waters of the Delaware River to live out the rest of its life as a museum.

Because of this, the zinc anodes didn’t corrode away as was intended. In fact when the dry dock was drained, it was revealed that the anodes were in nearly perfect condition. You could even still read the manufacturing info stamped into many of them. On the plus side, they’ll make for excellent souvenirs in the museum’s gift shop. But in terms of corrosion protection, they didn’t do a thing.

Luckily, fresh water is relatively forgiving, so the battleship didn’t suffer too badly for this lack of functioning cathodic protection. Even so, it was decided to install 600 aluminum anodes in place of the originals, which are more suitable for the conditions the ship is stored in.

Closing Off the Shafts

Before New Jersey went in for this yard period, there was some debate about removing its propellers and drive shafts. The idea being that the huge openings in the hull which the shafts pass through were a long-term liability. But not only would this have deviated from the museum’s overall goal of keeping the ship as intact as possible, it would have been a considerable undertaking.

Instead it was decided to seal off where the shafts pass through the hull with custom-made steel enclosures, much like the other openings on the bottom of the ship. In addition, the shafts were wrapped with fiberglass where they pass through the support brackets on the rear of the ship. The fiberglass isn’t expected to be a permanent solution like the steel boxes around the shafts, but should provide at least some measure of protection.

Lots and Lots of Caulk

One of the surprising things discovered upon inspecting the hull of New Jersey was that caulking had been applied to all the seams along the riveted hull plates. At least in theory, this shouldn’t be necessary, as the overlapping plates are designed to be watertight. But if the Navy thought it was worth the time and expense to do it, there must have been a reason.

Sure enough, a dive into the ship’s onboard reference library revealed a document from October of 1990 that described a persistent water intrusion issue on the ship. Basically, water kept getting inside the hull, but they couldn’t figure out where it was coming from. Although the Navy couldn’t actually find any leaks between the hull plates, the document went on to explain that the decision was made to caulk them all anyway in hopes that it would solve the issue.

Since the ship hadn’t been taking on any mysterious water while docked in Camden, it would appear the fix worked. As such, it was decided to re-caulk the roughly 18,000 linear feet (5,500 meters) of plate seams just like the Navy did in 1990. Since the manufacturer of the product was mentioned in the document, the museum was even able to get the exact same caulking used by the Navy 34 years ago.

Views From Dry Dock

Documentation for the Future

Walking along the ship’s massive hull, the projects I’ve listed here were the most obvious to even the untrained eye. But as I said at the start, this isn’t a complete list of the work done to the USS New Jersey during its dry docking. It’s hard to overstate the scale of the restoration work that was accomplished in such a short amount of time. It took years of planning by a team of very dedicated individuals to pull this off.

But you don’t have to take my word for it. Ryan Szimanski and his team have done an incredible job of documenting the entire dry docking process on the ship’s official YouTube channel. Putting all of this information out for the public to view and learn from will undoubtedly inform the restoration efforts on other museum ships going forward, but even if you don’t have a battleship in your backyard, it makes for fascinating viewing.

youtube.com/embed/jcScaxaF2PQ?…

Air ride suspensions have several advantages over typical arrangements, but retrofitting a system to a vehicle that didn’t come with it can get pricey fast, especially if you want to go beyond the basics. The Open Source Air Suspension Management Controller aims to give people a fully customizable system without the expense or limitations of commercial units.

The project started as an upgrade to a basic commercial system, so it assumes that you’re bringing your own “bags, tank, compressor, tubing and fittings, gauges and manual paddle switches.” The current board uses an Arduino Nano, but the next revision based on the ESP32 will allow for a wider feature set.

With a Bluetooth connection and Android app, you can control your ride height from a phone or integrated Android head unit. Currently, the app shows the pressure readings from all four corners and has controls for increasing or decreasing the pressure or airing all the way up or down to a given set point.

Want to know how air suspensions work? How about this LEGO model? If you want a suspension with active tuning for your bike, how about this Arduino-powered mod?

Questo Memories Have Faces esce a quasi dieci anni di distanza da Inside Out Your Mind, ultimo vagito su trentatré della band, dimostrandosi, a mio modesto avviso, ancora superiore al suo già di per sé brillantissimo predecessore;  a riprova, se mai ce ne fosse bisogno, di come passione, competenza e sacro fuoco non abbandonino chi di certe sonorità si è reso uno dei più credibili e quotati alfieri.

@Musica Agorà

iyezine.com/the-loons-memories…

The Loons - Memories Have Faces

The Loons - Memories Have Faces - The Loons - Dream In Jade Green - The Loons

^{Il Santo (In Your Eyes ezine)}

Ad ulteriore dimostrazione di quanto ho scritto in occasione delle sue precedenti uscite, i nove pezzi di questo nuovo album si aprono con suggestioni tra il deserto e lo spazio infinito di Dirty Ground passando poi all'andamento doloroso di Light the Incense.
@Musica Agorà

iyezine.com/black-snake-moan-l…

Black Snake Moan - Lost In Time 

Black Snake Moan - Lost In Time  - Black Snake Moan - Lost In Time: - Black Snake Moan

^{Il Santo (In Your Eyes ezine)}

“The healer” su Thrill Jockey Records è il quinto disco sulla lunga distanza per i Sumac, gruppo di punta del rumorismo e della totale libertà musicale. Il gruppo formato da Nick Yacyshyn, Brian Cook e Aaron Turner torna a disegnare ardite parabole nei consumati cieli della musica moderna. @Musica Agorà

iyezine.com/sumac-the-healer

Sumac - The healer

Sumac - The healer - Sumac: una delle più particolari e meravigliose esperienze sonore che possiate compiere in questi tempi aridi. - Sumac

^{Massimo Argo (In Your Eyes ezine)}

I did something recently I haven’t done in a long time: I recompiled the Linux kernel. There was a time when this was a common occurrence. You might want a feature that the default kernel didn’t support, or you might have an odd piece of hardware. But these days, in almost all the cases where you need something like this, you’ll use loadable kernel modules (LKM) instead. These are modules that the kernel can load and unload at run time, which means you can add that new device or strange file system without having to rebuild or even restart the kernel.

Normally, when you write programs for Linux, they don’t have any special permissions. You typically can’t do direct port I/O, for example, or arbitrarily access memory. The kernel, however, including modules, has no such restriction. That can make debugging modules tricky because you can easily bring the system to its knees. If possible, you might think about developing on a virtual machine until you have what you want. That way, an errant module just brings down your virtual machine.

History

Some form of module support has been around since Linux 1.2. However, modern kernels can be built to include support for things or support them as modules. For example, you probably don’t want to put drivers for every single known video card in your kernel. But it is perfectly fine to build dozens or hundreds of modules you might need and then load the one you need at run time.

LKMs are at the heart of device drivers, file system drivers, and network drivers. In addition, modules can add new system calls, override existing system calls, add TTY line disciplines, and handle how executables run.

In Use

If you want to know what modules you have loaded, that’s the lsmod command. You’ll see that some modules depend on other modules and some don’t. There are two ways to load modules: insmod and modprobe. The insmod command simply tries to load a module. The modprobe command tries to determine if the module it is loading needs other modules and picks them up from a known location.

You can also remove modules with rmmod assuming they aren’t in use. Of course, adding and removing modules requires root access. You can usually run lsmod as a normal user if you like. You might also be interested in depmod to determine dependencies, and modinfo which shows information about modules.

Writing a Module

It is actually quite easy to write your own module. In fact, it is so simple that the first example I want to look at is a little more complex than necessary.

This simple module can load and unload. It leaves a message in the system messages (use dmesg, for example) to tell you it is there. In addition, it allows you to specify a key (just an arbitrary integer) when you load it. That number will show up in the output data. Here’s the code:
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/printk.h>

MODULE_AUTHOR("Al Williams");
MODULE_DESCRIPTION("Hackaday LKM");
MODULE_LICENSE("GPLv2"); // many options, GPL, GPLv2, Proprietary, etc.

static int somedata __initdata=0xbeef; // this is just some static variable available only at init
static int key=0xAA; // you can override this using insmod
// Note 0644 means that the sysfs entry will be rw-r--r--
module_param(key,int,0644); // use module_param_named if you want different names internal vs external
MODULE_PARM_DESC(key,"An integer ID unique to this module");

static int __init had_init(void)
{
// This is the usual way to do this (don't forget \n and note no comma after KERN_INFO), but...
printk(KERN_INFO "Hackaday is in control (%x %x)\n",key,somedata);
return 0;
}

static void __exit had_exit(void)
{
// ... you can also use the pr_info macro which does the same thing
pr_info("Returning control of your system to you (%x)!\n",key);
}

module_init(had_init);
module_exit(had_exit);</pre>

This isn’t hard to puzzle out. Most of it is include files and macros that give modinfo something to print out. There are some variables: somedata is just a set variable that is readable during initialization. The key variable has a default but can be set using insmod. What’s more, is because module_param specifies 0644 — an octal Linux permission — there will be an entry in the /sys/modules directory that will let the root set or read the value of the key.

At the end, there are two calls that register what happens when the module loads and unloads. The rest of the code is just something to print some info when those events happen.

I printed data in two ways: the traditional printk and using the pr_info macro which uses printk underneath, anyway. You should probably pick one and stick with it. I’d normally just use pr_info.

Building the modules is simple assuming you have the entire build environment and the headers for the kernel. Here’s a simple makefile (don’t forget to use tabs in your makefile):
<pre>obj-m += hadmod1.o

PWD := $(CURDIR) # not needed in most cases, but useful if using sudo

all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean</pre>

Once you build things, you should have a .ko file (like hadmod.ko). That’s the module. Try a few things:

1. sudo insmod hadmod.ko # load the module
2. sudo dmesg # see the module output
3. cat /sys/modules/hadmodule/key # see the key (you can set it, too, if you are root)
4. sudo rmmod hadmod.ko # unload the module
5. sudo insmod hadmod.ko key=128 # set key this time and repeat the other steps

That’s It?

That is it. Of course, the real details lie in how you interact with the kernel or hardware devices, but that’s up to you. Just to give a slightly meatier example, I made a second version of the module that adds /proc/jollywrencher to the /proc filesystem. Here’s the code:
#include <linux/init.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/printk.h>
#include <linux/uaccess.h>
#include <linux/fs.h>
#include <linux/proc_fs.h> // Module metadata
#include <linux/version.h>

MODULE_AUTHOR("Al Williams");
MODULE_DESCRIPTION("Hackaday LKM1");
MODULE_LICENSE("GPLv2"); // many options, GPL, GPLv2, Proprietary, etc.

static char logo[]=
" \n"\
" \n"\
" \n"\
" #@@@@@@ ,@@@@@@ \n"\
" &@@@@@* &@@@@@, \n"\
" @@@@@@% @@@@@@# \n"\
" @@ .@@@@@@@@@ .@@@@@@@@@ .@# \n"\
" &@@@& /@@@@@@@@@@@@ @@@@@@@@@@@@ @@@@* \n"\
" @@@@@@@@@@@@@@@@@@@@@# @@@@@@@@@@@@@@@@@@@@@, \n"\
" &@@@@@@@@@@@@@@@@@@@@@* ,@@@@@@@@@@@@% &@@@@@@@@@@@@@@@@@@@@@* \n"\
" ,*. @@@@@@@@@@@/ .@@@@@@@@@@@@@@@@@@@@& &@@@@@@@@@@# ** \n"\
" @@@@@@, &@@@@@@@@@@@@@@@@@@@@@@@@@, %@@@@@& \n"\
" ,@& /@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@ \n"\
" &@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@* \n"\
" %@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@. \n"\
" @@@@@@ #@@@@@@@. /@@@@@@ \n"\
" /@@@@& @@@@@@. @@@@@ \n"\
" ,@@@@% (@@@@@@@@@@&* @@@@@ \n"\
" @@@@@# @@@@@@@@@@@@@@@@@@% @@@@@& \n"\
" /@@@@@@@@@@@@@@@, #@@@@@@@@@@@@@@@ \n"\
" @@ *@@@@@@@@@@@@@& ( @@@@@@@@@@@@@@ .@( \n"\
" %@@@@@. @@@@@@@@@@@@@@@@@@@@@@@@@@@@% #@@@@@* \n"\
" (%&%((@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@% ,@@@@@@@@@@*#&/ \n"\
" @@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@( @@@@@@@@@@@@@@@@@@@@@& \n"\
" @@@@@@@@@@@@@@@@@@@@@ @@@@@@*@@@@@@/%@@@@@& *@@@@@@@@@@@@@@@@@@@@# \n"\
" @@@@. @@@@@@@@@@@. .. . . (@@@@@@@@@@# /@@@* \n"\
" @, %@@@@@@@@ .@@@@@@@@. \n"\
" ,@@@@@( @@@@@@ \n"\
" *@@@@@@ (@@@@@@ \n"\
" @@@@@@, %@@@@@@ \n"\
" \n"\
" ";

static struct proc_dir_entry *proc_entry;
static ssize_t had_read(struct file *f, char __user * user_buffer, size_t count, loff_t * offset)
{
size_t len;
if (*offset>0) return 0; // no seeking, please!
copy_to_user(user_buffer,logo,len=strlen(logo)); // skipped error check
*offset=len;
return len;
}

#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,6,0)
static struct proc_ops procop = // prior to Linux 5.6 you needed file_operations
{
.proc_read=had_read
};
#else
static struct file_operations procop =
{
.owner=THIS_MODULE,
.read=had_read
#endif

static int __init had_init(void)
{
// This is the usual way to do this (don't forget \n and note no comma after KERN_INFO), but...
printk(KERN_INFO "Hackaday<1>; is in control\n");
proc_entry=proc_create("jollywrencher",0644,NULL,&procop);
return 0;
}

static void __exit had_exit(void)
{
// ... you can also use the pr_info macro which does the same thing
pr_info("Returning control of your system to you...\n");
proc_remove(proc_entry);
}

module_init(had_init);
module_exit(had_exit);

The only thing here is you have an extra function that you have to register and deregister with the kernel. However, that interface changed in Kernel 5.6, so the code tries to do the right thing. Until, of course, it gets changed again.

Once you load this module using insmod, you can cat /proc/jollywrencher to see your favorite web site’s logo.

Of course, this is a dead simple example, but it is enough to get you started. You can grab all the source code online. One great way to learn more is to find something similar to what you want to build and take it apart.

We don’t suggest it, but you can write an LKM in Scratch. If you really want to learn the kernel, maybe start at the beginning.

VMware ha risolto una serie di vulnerabilità critiche in vCenter Server, tra cui l’esecuzione di codice in modalità remota e l’escalation dei privilegi locali.

Gli sviluppatori hanno fornito correzioni per tre problemi contemporaneamente: CVE-2024-37079, CVE-2024-37080, CVE-2024-37081.

• CVE-2024-37079 : una vulnerabilità critica di heap overflow nell’implementazione del protocollo DCERPC in vCenter Server che consente a un utente malintenzionato con accesso alla rete di inviare pacchetti appositamente predisposti e potrebbe potenzialmente portare all’esecuzione di codice in modalità remota (punteggio CVSS 9,8).
• CVE-2024-37080 : un altro problema critico di heap overflow nel protocollo vCenter Server DCERPC. Come CVE-2024-37079, consente a un utente malintenzionato con accesso alla rete di sfruttare un overflow dell’heap inviando pacchetti modificati, che possono portare all’esecuzione di codice remoto (punteggio CVSS 9,8).
• CVE-2024-37081 : esiste una vulnerabilità dovuta a un’errata configurazione di sudo in vCenter Server, che consente a un utente locale autenticato di sfruttare il bug per aumentare i propri privilegi a root (7.8 sulla scala CVSS).

Gli errori elencati riguardano VMware vCenter Server versioni 7.0 e 8.0, nonché VMware Cloud Foundation versioni 4.x e 5.x.

Le patch per VMware vCenter Server erano incluse nelle versioni 8.0 U2d, 8.0 U1e e 7.0 U3r. E per Cloud Foundation, sono state aggiunte correzioni in KB88287.

Secondo il produttore non esistono contromisure alternative efficaci per queste vulnerabilità, pertanto si consiglia a tutti gli utenti di installare gli ultimi aggiornamenti il ​​prima possibile.

L'articolo VMware vCenter Server: 2 RCE da 9,8 di score e una Privilege Escalation da Patchare subito proviene da il blog della sicurezza informatica.

This is the Central Scrutinizer...
It is my responsibility to enforce all the laws
That haven't been passed yet
It is also my responsibility to alert each
And every one of you to the potential consequences
Of various ordinary everyday activities
You might be performing which could eventually lead to
The Death Penalty (or affect your parents' credit rating)
Our criminal institutions are full of little creeps
Like you who do wrong things...
And many of them were driven to these crimes
By a horrible force called music!

Our studies have shown that this horrible force
Is so dangerous to society at large that laws
Are being drawn up at this very moment to stop it forever!
Cruel and inhuman punishments are being carefully described
In tiny paragraphs so they won't conflict with the Constitution
(Which, itself, is being modified in order to accommodate the future)

I bring you now a special presentation
To show what can happen to you if you choose a career in music...
The white zone is for loading and unloading only...
If you have to load or unload, go to the white zone...
You'll love it... it's a way of life... Ha, ha, ha, ha, ha...
Hi, it's me, I'm back
This is the Central Scrutinizer...
The white zone is for loading and unloading only...
If yah gotta load, or if yah gotta unload, go to the white zone
You'll love it... it's a way of life
That's right, you'll love it, it's a way of life
That's right, you'll love it, it's a way of life
You'll love it
This, is, the Central Scrutinizer!
- Frank Zappa

iv.datura.network/watch?v=IgG8…