Leaving UN, One Blob At A Time

In the news was that the USA left the UN Human Rights Council:

https://www.voanews.com/a/us-leaves-un-human-rights-council-citing-bias/4445718.html

US Leaves UN Human Rights Council, Citing Bias

STATE DEPARTMENT —

The United States has announced its official withdrawal from the United Nations Human Rights Council, saying the organization is no longer worthy of its name.

At a joint press availability at the State Department Monday with Secretary of State Mike Pompeo, U.S. Ambassador to the U.N. Nikki Haley told reporters, “For too long, the Human Rights Council has been a protector of human rights abusers and a cesspool of political bias.”

She accused the council of “chronic bias” against Israel.

She said the U.S.had tried for the past year to reform the council, but to no avail, adding.

“Look at the council membership, and you see an appalling disrespect for the most basic rights,” she said, citing human rights abuses by Venezuela, China, Cuba and Democratic Republic of Congo.

A refreshing bit of honesty at the UN. (Not by the UN…)

Then I found there is a “Fox News” app on the Roku that lets you watch snips of their cable shows and time delayed (to nudge you to buy cable for real time access). As I don’t really need real time political opinions, this was a fine way to see an interview with John Bolton. Both he, and our present UN Ambassador Nikki Haley had said we didn’t need them telling us how to live and all we really needed to do was follow our constitution. I was wondering what that was all about, and found out the UN_HRC had been wanting us to get rid of the 2nd Amendment.

https://www.thenewamerican.com/usnews/constitution/item/17998-un-human-rights-report-attacks-u-s-gun-rights-constitution

Monday, 07 April 2014

UN “Human Rights” Report Attacks U.S. Gun Rights, Constitution

The United Nations pseudo-“human-rights” bureaucracy released another report attacking Americans’ self-defense rights, “Stand Your Ground” statutes passed at the state level, and the U.S. Constitution’s Second Amendment protection of the people’s God-given right to keep and bear arms without government infringement. Agreeing with the Obama administration and the most extreme anti-Second Amendment members of Congress, the UN “Human Rights Committee” also claimed that the U.S. government needed to expand the unconstitutional background-check regime to include even private firearms sales.

In a section of the report entitled “gun violence,” the UN “experts,” virtually all of whom come from governments that do not recognize the fundamental human right to possess weapons or of self-defense, claimed to be “concerned” about multiple issues surrounding U.S. gun laws. Despite “measures taken to reduce gun violence,” an advance of the UN document claims, “the Committee remains concerned about the continuing high numbers of gun-related deaths and injuries and the disparate impact of gun violence on minorities, women and children.” It was not immediately clear where the outfit obtained its data.
[…]
“The State Party [the U.S. government] should take all necessary measures to abide by its obligation to effectively protect the right to life,” the report continues, despite the fact that studies show widespread gun ownership protects lives. “In particular, it should: (a) continue its efforts to effectively curb gun violence, including through the continued pursuit of legislation requiring background checks for all private firearm transfers … and (b) review Stand Your Ground Laws to remove far-reaching immunity and ensure strict adherence to the principles of necessity and proportionality when using deadly force in self-defence.”

In other words, the UN is now brazenly and openly pushing for radical and unconstitutional changes to both U.S. and state law. In particular, the report is calling for a massive expansion of the background-check regime — a plot that was so extreme it did not even make it through the Democrat-controlled U.S. Senate amid a full-blown assault on gun rights by the Obama administration. Critics have attacked the controversial idea from all angles, but especially troublesome are the constitutional implications, as well as well-founded suspicions that the Obama administration is unlawfully trying to use background checks to compile a national gun registry in defiance of federal law.

An interesting additional link from the Democrat Machine back to International agencies advocating the Progressive / Socialist / Central Authority agenda. Food for thought there.

Which got me wondering just how much we were paying these jerks to tell us to get rid of our Constitution and talk dirt about Israel? How much of Our Money was being leveraged against Us?

https://www.cfr.org/article/funding-united-nations-what-impact-do-us-contributions-have-un-agencies-and-programs

In 2016, the United States remained the largest donor to the United Nations, contributing more than $10 billion, roughly one fifth of its collective budget. The arrival of the Trump administration, however, has raised questions about how much the United States will continue to contribute. If President Donald J. Trump is able to follow through on his proposed cuts to foreign aid spending, the United Nations will likely need to undergo significant changes.

One fifth of the total UN budget or about 20%. From one country. Us.

And oh yeah, I hope the U.N. will “need to undergo significant changes”.

There are some interesting charts and graphs in that article. One has a “bubble” with size proportional to price, pardon, cost, oh, pardon again “contribution”… Has UN-HCR (that’s the “refugees” i.e. invade your country program) at $1.5 Billion. It is in orange type, so an “assured budget”. We stuff $2.4 Billion / year into “peacekeeping” (which doesn’t seem to keep the peace very much but does give third world soldiers a chance to have sexual liaisons with children in foreign lands, per the Haiti reports).

President Trump’s 2018 budget proposal [PDF] would take a knife to several UN bodies. It would halt all U.S. payments to UN climate change programs and cap the U.S. contribution to the peacekeeping budget at 25 percent, down from the 28 percent currently required from the DPKO. Trump has also proposed [PDF] paring back the United States’ voluntary payments to many other UN entities, including UNICEF, which could see a 16 percent decrease in its total revenue.

My God, isn’t it wonderful to see someone who knows how to cut fat from budgets take a whack at the UN Bloat!

The law required that the United States pay no more than 25 percent of the UN peacekeeping budget. For many years Congress has waived this ceiling to keep up with rising assessments from the Department for Peacekeeping Operations.

If only Congress would catch a clue… (Somebody needs to buy Trump a nice big fat Clue Stick to whack them with..)

But it remains unclear how much of the president’s proposals will survive the federal budget process. In September, the U.S. Senate Appropriations Committee approved a spending bill that would keep in place payments to the UN climate body and United Nations Population Fund. That same month, during his first speech at the UN General Assembly, Trump said, “The United States bears an unfair cost burden, but to be fair, if [the United Nations] could actually accomplish all of its stated goals, especially the goal of peace, this investment would easily be well worth it.”

The next opportunity for the United States to negotiate its assessed contributions with the UN will be fall 2018.

As we enter fall of 2018, I’m hoping his cost cutting can get into full gear.

So far I’ve not found just how much budget walks from the HR Council with the US exit, or if it is funded out of the general budget as an assured teat to suck upon. I would hope that it is one with a “voluntary” funding and that our $$ walked with us.

Near as I can tell, the entire UN is a waste of space. It is filled with the Global Shithole Leaders and mostly just advocates for anything BUT liberty and freedom. It has a major bias against the USA and mostly just makes noise.

But I understand, we can’t just exit the whole thing all at once. Besides, we created it. There’s also some benefit from having a veto on the Security Council to keep it from doing the most incredibly stupid and damaging things. Still, it’s nice to see us leaving some parts of it; even just one council at a time. After all, a $Billion here, a $Billion there, pretty soon you are saving some real money out of our $10 Billion / year funding that rat hole.

Subscribe to feed

Advertisements

My Magnificent Bastard System

After a few days of banging my head on the wall of an amrhf (32 bit) Devuan 2.0 release that just Did Not Run on my Raspberry Pi M3, and finding the FireFox on the arm64 (64 bit) Devuan 2.0 release just painfully slow, over the last 24 hours “I’ve created a monster!” ;-)

Essentially, I took a page from the first days of 64 Bit arm systems when the Linux kernel was new and userland was basically not ported to 64 bit.

I took the 64 bit install, and shoved it onto a mini-SD card. Then I made another partition where I could copy all of the / (root) file system of the armhf 32 bit version. Essentially, you keep all the stuff on the MSDOS partition from the 64 bit install (kernel, cmdline.txt config… etc.) and then change the cmdline.txt so it points to the partition where you un-tarred the 32 bit userland.

The one “tricky bit” is that kernel modules (loaded for things like network device drivers) are located in /lib/modules and you can’t run 32 bit modules in a 64 bit kernel. So you toss the 32 bit and copy in the 64 bit. Then you can do your first boot.

That’s basically it. Runs a champ!

Now I also decided to complexify things mightily while I was at it. At first I did the install into an 8 GB chip, then decided it wasn’t big enough for 2 whole systems, so moved to a 16 GB chip, but only AFTER having installed both, so I couldn’t effectively make the desired file system larger… which resulted in my making 3 more file systems on the chip and moving /var /usr and my home directory onto them.

Yeah, a bit messy, but lets me see just how big each one is with a df command AND sets me up for moving them onto a hard disk mounted partition OR using a squashfs file based file system for /usr to make it resistant to changes. (Once I’m done changing it, that is!) Just for kicks, I also made the added /var /usr and /home/chiefio partitions as xfs file systems. (So you must apt-get install xfsprogs on the system where you grab a copy of userland so it will be there at boot time…)

Here’s the final df output:

chiefio@devuan:~$   df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/root        1743136  211904   1441020  13% /
devtmpfs          438328       0    438328   0% /dev
tmpfs              88764    1596     87168   2% /run
tmpfs               5120       4      5116   1% /run/lock
tmpfs             177520       0    177520   0% /run/shm
/dev/mmcblk0p1    130798   35754     95044  28% /boot
/dev/mmcblk0p3   4062912 2854276    998924  75% /arm64
/dev/mmcblk0p5   3135488  596576   2538912  20% /var
/dev/mmcblk0p6   4184064 1692296   2491768  41% /usr
/dev/mmcblk0p7   2073600  574264   1499336  28% /home/chiefio
tmpfs             443800       0    443800   0% /sys/fs/cgroup
tmpfs              88760       8     88752   1% /run/user/0
tmpfs              88760      16     88744   1% /run/user/1000

The /dev/root file system is the /dev/mmcblk0p2 slice and that is where the basic armhf file system is installed. I put the arm64 root in /arm64. It isn’t used, I just left it there for reference. Also, by changing the cmdline.txt file I still could boot in full 64 bit mode.

Here’s the cmdline.txt:

dwc_otg.fiq_fix_enable=2 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext3 rootwait rootflags=noload net.ifnames=0

Note that I’ve made the file systems ext3 (instead of the default rootfstype=ext4) and you just change that root=/dev/mmcblk0p[2-3] to either 2 or 3 to change which userland boots.

When you install more software with apt-get, it caches the new programs .deb package in /var and then the actual install happens into /usr (usually). So both of those are where the growth happens as you fill out a system with all the “stuff” you want in it. When done configuring: /usr is relatively static (as all the ‘variable’ stuff was moved to /var some decades back). That means /usr can be mounted read only or even as a squashf file system on static finished configurations. (A minor added security measure).

Then /boot, the mmcblk0p1 partition on the chip, is the MSDOS FAT32 partition with all the boot loader code, kernel, etc.

Assessment

Well, it’s only been running about an hour now, so this is very preliminary.

First off, FireFox works (yay!) unlike in the last update to Devuan 1.0 or the too painful to use arm64 Devuan 2.0 install. Not super fast, but fast enough. I’m composing / posting this article using it.

It is a little slower than the full armhf system. Not much, just enough to notice. Likely as the 64 bit kernel is not as highly polished as the 32 bit and is moving 2 x as much data for every word fetch. Still, it’s better than nothing (the armhf failed install) or the fully fat and slow all 64 bit.

I’ve not seen any technical issues from running (yet…) and everything seems to run stable and well.

I’m going to be using this as my basic test drive workstation for Devuan 2.0 for a while. I’ll sporadically swap to the Devuan 1.0 Daily Driver for “compare and contrast”. Just to see if my speed perceptions are accurate, or being shifted by subconsciously comparing to the XU4 or Mac ;-) Basically, I’m going to keep myself calibrated as to what the experience is supposed to be.

This particular chip did NOT impress me as being the fastest when I was copying GB onto it. Also, having it chopped up into 7 file systems and putting ALL I/O load onto it is also likely less than ideal. When I last did a “file systems on real disk” test, some year+ ago, that made a BIG difference. So for the rest of tonight and on into next week, I’ve got a 1 TB USB disk I’m going to be formatting and setting up to take a load of the I/Os and see what happens to speed then.

In Conclusion

I’m quietly pleased with myself for making this hybrid 64 bit / 32 bit system. It isn’t all that hard, but it does take a certain attitude, and understanding, to think of “going there”. But that whole necessity thing was kind of in my grill. IF I wanted to test armhf Devuan 2.0, I either had to wait for someone to fix the released copy (I’m pretty sure now it wasn’t me causing it to not work), try it on a PC instead of an SBC, figure out what was wrong and fix it myself, or ‘get creative’. I chose creative as it’s more fun ;’)

This also lets me add all sorts of software without much worry as to what running on a back-level 1.0 release kernel would do (remember that I first got armhf Devuan 2.0 userland running on an older kernel here: https://chiefio.wordpress.com/2018/06/12/devuan-2-0-ascii-release-r-pi-install-tale-of-woe/) While satisfying that I could “make it go” and narrow the scope of where the problems were located, it limits the ability to reasonably test a new userland as any bug could be old kernel mismatch issues. Where 32 bit userland on 64 bit kernel is supposed to work.

Now you know why I’ve been somewhat quiet the last couple of days and not commenting quite so much on the political scene. I’ve been up to my eyeballs in bit shoveling ;-) Now that I’ve scratched this itch, I can come up for air and see what has happened in the world… other than World Cup and Trump Bashing… Or maybe that’s the empty set right now ;-)

Subscribe to feed

Dueling Foundations, Lawfare, Happy Birthday Mr. President, IG Report

Happening now, the release of the I.G. report, on POTUS Donald Trump’s Birthday.
One hopes it is a very nice birthday present…

So not much to say yet, but here’s a place to say it as the “stuff” hits the whirly thing.

In other news, the New York Democratic Lawfare Organization has decided to sue / attack / whatever… the Trump Foundation claiming all sorts of improprieties (and no doubt that they kicked the dog too.. /sarc;) so another “watch this space”. Looks like they are suing POTUS and his kids. It’s a civil suit, so money damages at most (though don’t be surprised to see someone try to expand this into criminal charges).

One wonders where the NYC Lawfare Division was when Hillary was running her “Pay to play” shakedown operation.

Not much to say about either at the moment, but here’s just a specific thread to accumulate the score as the battles expand the field…

Subscribe to feed

Devuan 2.0 “ASCII” Release R. Pi Install Tale Of Woe

It is now 9:30 PM on Monday. I started down this path sometime Saturday. What ought to have been a “3 hour tour” has taken a bit longer…

I’ll give you the very abbreviated form, skipping the half dozen times I tried slight variations on a theme and had nothing happen differently and the half dozen times I got to do that half dozen over again as I found a bit of hardware had failed…

The Basic Process

I downloaded the various new Devuan 2.0 “ASCII” code name files from a mirror site. They changed where you get them from, so now you get to pick a mirror. One was fairly dog slow, and another blindingly fast. I stayed with the fast one… a .edu site on a weekend.

Then the usual unpacking (unxz) and you get the binary blob that is an SD card image and dd it onto the chip, in the computer and “Bob’s your Uncle” up it comes! Oh Boy!

Problem #1):

It builds a roughly 2 GB file system on your SD card that you then get to manually expand. No problem, just use gparted on another version… EXCEPT, they have gone to the “new” EXT4 that is different from the “old” EXT4 (but has exactly the same name…) and since the journals are different, “old” gparted can’t handle it. Now one could just use the NEW gparted, if they could install it, in the space that’s too small to install LXDE and gparted (g for Graphical..). Basically if you could install it then you could use it to let you install it… Sigh.

I chose not to expand the file system ‘long hand’ at the command line interface… Instead, I used the Devuan 1.0 system, that is my Daily Driver, to tar off the contents, then replace the offending ext4 with an ext3, then put back the tar archive files.

At that time you also get to change /boot/cmdline.txt to say ext3 instead of ext4 also (on the msdos partition).

That let it boot and all was fine. I’d done this with the arm64 64 Bit version for Raspberry Pi.

ARM64 Is Fat and Slow

Well, just like last time, the Arm64 version is fat and slow. Memory gets used up with just 3 open tabs and it’s off to swap land, where swap to SD card is also slow. It does work, but the armhf 32 bit version uses less memory and is somewhat faster to load things (as reading an SD card is the speed limit and 64 bit words take twice as much transfer as 32 bit words for the same number of words). Someday they will have optimized the 64 bit code and done things like us the “thumb” codes to make it smaller and faster. But right now they are still in the “just make it go” stages.

So I decided to use the 32 bit Armhf Raspberry Pi Model 2 code copy instead.

Armhf doesn’t boot in Pi M3

It has always been fine to run the 32 bit op codes / programs in the 64 bit Pi M3. For reasons I’ve only barely figured out, it did not want to run with what was shipped. Skipping about 8 hours of today: I got it to work by just brute force copy of everything from the old Devuan 1.0 /boot into the Devuan 2.0 /boot. Some binary blob in the process isn’t quite right, IMHO.

Now it boots, and I’m happy.

Getting There is 1/2 the Misery!

So what took so long?

First off, for several hours I had intermittent issues with SD cards that would NOT boot and sometimes became unreadable. Even to the point where launching gparted would hang the session. ( I resorted to having a window open as root and in it, I’d launch the command: sleep 5m ; halt )

That way, in 5 minutes, the machine would shut down gracefully if my session hung. Then I’d launch gparted and if it hung, go make coffee. If not, I’d kill the command in the other window.

So what was going on?

Problem #2):

Turns out the little adapter I was using to read / write the micro-SD cards (a USB / SD thing) was failing. At the end of the day it was reliably not writing the Master Boot Record. It took a while to figure that out. I have two of them and usually don’t care which one is used for what. Had to get past that habit. That took a few hours to figure out, just because you don’t really expect a basically passive device to fail. Then you especially don’t expect it to fail in just such a way that the OTHER file systems get written but the MBR fails. I still don’t know how that can be.

Now add in that even once it was replaced, the armhf copies would not boot anyway, and it’s a 2-fer trying to figure out which thing is the issue. The “breakthrough” came when I had a known good chip in it and gparted would not display the information, but moving that chip to the other carrier worked. Eureka!

Then several more hours working out that the armhf was STILL not going to boot the Pi M3 anyway and it was NOT device related…

At that point I went to unpacking the tarball version they also have. Un-tarred it, stuck the /boot stuff on the MS FAT32 partition and the rest on the ext3 partition (all created and “lba” flag set in gparted by hand) and expected “This Time For Sure!”… no joy again…

Problem #3):

That’s when I went through looking at the stuff in /boot (MS DOS partition). It’s a lot of binary blobs, the kernel, and a few txt config files. I chose to just pick up the whole set from Devuan 1.0 and stuff them in. At that point it booted and ran. So “something” in the /boot partition is bogus for the Pi M3.

I need to go back and narrow it down at some point. I’d like to get the newer kernel, so that’s the first thing I’m going to try. Hopefully it’s just the binary blob that’s the GPU boot loader code.

It is quite likely that something in the rest of the system will not work quite right with an older kernel so just running it is a risk, though all the basics are usually OK. Still, the whole idea of the upgrade is to, well, upgrade.

And Now?

Now I’m going to go back to watching The Trump & Un Show on the news. It’s been a very frustrating couple of days, mostly due to things that ought to “just work” not working.

My path “going forward” is for tomorrow to swap in the new kernel, and then maybe check what other bits might be interesting, and call it “good enough”. After that, the usual 2 or 3 hours of adding in all the bits of applications and systems software I typically use (my “Build Script” stuff) and then I’ll start unpacking my home directory archive into this brand new space.

I’d decided that if I was going to be sorting out the various backups of my home directory, I might as well make this an entirely new and full system. Little did I realize that was going to be a “3 day decision”…

But by Friday all ought to be fully recovered, brand new system build, and lots of legacy crap jettisoned. (like all the browser cache). Somewhere along the way this weekend, Firefox, on the current Daily Driver, started to do consistent hard crash on launch. Don’t know if it’s a Firefox thing or a “my cache” thing, but I’m just going to do a new install on Devuan 2.0 and move on anyway.

At present, I’m doing my browsing on the Mac or on the XU4 Odroid. I tried at one point to get Devuan 2.0 to run on it, as well, but it would not boot. Now I’m thinking maybe that was the fault of the USB adapter too. So “someday” I’m going to try again with the known working one and answer that question. I can’t believe that Devuan would ship 2 images that both don’t even boot on the target hardware. (My guess is maybe they tested the Pi M2 image on a Pi M2, but not a Pi M3; and that mode of failure ought not to apply to the XU4… unless they only tested on an XU{something else}.)

But that’s for tomorrow, or maybe the next day. For now, it’s late, I’m burnt out, and I’m going to veg; well away from operating installations and making file systems and dd image moves…

Subscribe to feed