Re: tricky but powerful source control tool
I personally find Mercurial to be much more user friendly and logical.
176 posts • joined 16 Mar 2013
I personally find Mercurial to be much more user friendly and logical.
Oh god, HP-UX? It’s trash compared to the one decent UNIX OS that they had and killed: Tru64!
I guess one of the big original selling points of Solaris x86 was that it would run SCO OpenServer binaries. While in theory Linux could, it was usually a big headache and prettty fragile back then. On Solaris it would pretty much just work, or at least that’s what I was told.
Where did the article say SPARC? Solaris has ran on AMD64 for a LONG time.
Me thinks you’re confused. AT&T bought DirecTV and neither of them bought DISH.
AdvFS was amazing. Sure, ZFS is better, but AdvFS brought a lot of features long before anybody else ever did.
Okay, I'll definitely agree with you that it compromises the security of the client. How, exactly, does serving a .swf however compromise the security of the SERVER? We're not talking Cold Fusion here!
There are literally hundreds of Linux distributions, and yet Illumos and BSD are your examples of fragmentation. REALLY?
What, your gear doesn't support using /31s for P2P links?
And not lib*g*crypt?!? :)
I believe libcrypt is OpenSSL
The article states:
"since the malware writers must have known that the email address would be shut down quickly, which cut off access to funds".
That's not true at all. BitCoin doesn't use email. The email was to tell the writers that you sent them a BitCoin so that in theory they'd email you back your decryption key. They can still receive the ransom even without access to the email account!
The rest wasn’t the file system itself. The test was the conversion!
I’m sure there was a thorough test before hand, and it was done in a way to insure that it couldn’t cause damage. What better would you recommend to test something major like this across every possible combinations of things?
AWS has managed to apply past XSAs without rebooting, so I'm not sure why you assume that this one will be any different?
I'll take any information that Linode provides with a huge chunk of rock salt.
Wow, Simon, did somebody in the Xen project cross you or something?
First off, the crazy 3^2 comment.
Second, the comment about how they want to reduce publicity and you linking it to your previous story. You know, the story where the Xen project team responded in the comments and explained exactly what was going on, and no, PR had nothing to do with it.
Then you mention that indeed, Xen has live patching (AWS has had it for ages), and yet put reboots in both the subhead and the body. Mass reboots sounds like a Linode problem, not a Xen problem.
Then the comment about mass migration to KVM. The comments in your previous story mention how KVM has bad security also (along with VMWare, Hyper-V, etc), they're just not as announced as such. There's a reason that the major cloud providers use Xen and not KVM. I'm sure if KVM was so much better than Xen, AWS wouldn't keep messing around with Xen!
The Linux kernel has had a few CVEs lately too.
As much as I love Linux, I've been leaning towards Illumos, NetBSD, and FreeBSD lately.
... and also handy things like the Tianocore UEFI shell, which can come in really handy and do things like configure hardware (CNEs, RAID controllers, etc) before the OS. UEFI GOP support, which is used heavily by FreeBSD's bhyve hypervisor, etc.
Intel ME and such has NOTHING to do with UEFI.
UEFI does add features, such as boot management without resorting to another layer like GRUB. Decent PXE support without using iPXE, etc. Also having your OS being able to write to the UEFI "console" and having that automatically go to the local screen, IPMI serial redirection, etc without having to reconfigure the OS ISO to point to an emulated serial port is awesome!
UEFI isn't tied to Intel. The same people making your old buggy BIOS is also making your new buggy UEFI, just without the last 40+ years of legacy crap that they're having to emulate.
UEFI itself is fine, it's just Secure Boot that needs to die.
And don't forget the Mach part too!
bob: say it with me: "NAT is NOT a security device!"
Just about any router worth its salt that can grok IPv6 can block inbound IPv6 connections by default just as easily as it can IPv4 without NAT. This is basic stateful firewalling aka connecion tracking in Linux. Hell Verizon Wireless does this automatically for all of their IPv6 clients.
Clones pretty much almost killed Apple last time. Why would they go down that same road again?
Property taxes are one thing, but CA's state income tax levels are completely insane. It would be one thing if property and/or sales taxes were lower because of it, but they're not.
Not to mention it's amazing build.sh build system that can pretty much build for any arch from not only any arch but also from almost any other OS!
Please. Both parties (actually ALL politicians for that matter!) are lying scumbags. I'm pretty that it's in the job description somewhere...
Nope. That's the Libertarian Party.
I think Alpha Processor Inc had a machine that would take either a Slot-B Alpha or AMD x86 CPU.
A lot of the AArch64 Linux distos actually seem to use u-boot to boot an EFI shim and then EFI boot the OS.
I believe the AArch64 server standards mandate UEFI.
Since when does MS have ANY expertise in emulation?
Their aborted Windows 2000 build for Alpha had x86 emulation, but it was just DECs FX!32 emulator from the NT days embedded. So it wasn't MSs code doing the emulation work.
Polarity switching? WTF are you smoking? The Note 7 issues had NOTHING to do with chargers. Samsung's own investigation even said it was two completely different BATTERY issues:
'After months of investigating, Samsung is pinning all the blame on two separate battery flaws, insisting nothing was wrong with the phone itself.
For those who want to get a bit nerdy, here’s what Samsung says was wrong with each battery. For the first battery, Samsung says a design flaw in the upper right corner of the battery made the electrodes prone to bend and, in some cases, led to a breakdown in the separation between positive and negative tabs, causing a short circuit.
With the second battery, which came from a separate supplier, Samsung believes there was nothing wrong with the design itself, but says a manufacturing issue led to a welding defect that prompted that battery to also short circuit and ignite.
Samsung said that its design for the Note 7, while demanding on its battery suppliers, was not unreasonable or the reason why the batteries failed. The issues with battery B, Samsung said, were tied to the fact that the supplier tried to quickly increase its production after battery A was pulled off the market.
“We believe if not for that manufacturing issue on the ramp [of battery B], the Note 7 would still be on the market,” Samsung Electronics America head Tim Baxter told Recode.'
Crazily enough, 4.9.12 was just released today and yet it doesn't appear to have the fix in it!
I never had any problems using PL/R in PostgreSQL, even in production.
The whole argument in this article about using Python instead isn't even a real comparison. Using server-side R vs client-side Python are two completely different things. If it involves retrieving huge amounts of data, even if R is slower, it's going to be faster on the server side as its not going to involve transferring huge amounts of data.
I pretty much agree exactly with BinkyTheMagicPaperclip. I think the biggest problem with Xen right now is that the code is moving somewhat too fast. Eg, PVH became HVMlite which became PVHv2 (or something along those lines). When the target is moving so fast, mistakes happen. On the flip-side, I think once PVHv2 is done and most people can completely skip the QEMU madness (except for Windows guests and such), the attack surface suddenly shrinks a lot. Right now with stub domains, however, it's still more secure than KVM.
I completely agree on KVM being a spaghetti web of different things patched together. Ironically I daresay the best KVM distribution around right now isn't even Linux-based, it's SmartOS. SmartOS hides a lot of the nastiness and makes KVM a lot easier to work with, and also more secure by isolating them off into Zones.
For Xen I've mainly used XenServer or NetBSD as a dom0, both have worked very well, although NetBSD doesn't support PVH mode currently (FreeBSD can run as a dom0 now too). For KVM, I've stuck with SmartOS. I've even added a lot of FreeBSD bhyve into the mix, which is very similar to KVM, except it doesn't use QEMU AT ALL. They all have their strengths and weaknesses. Xen's live patching is definitely a huge plus in its favor, however.
Sort of like how RedHat pretty much "owns" KVM? Yes, I know it's a Linux Foundation project now, but RedHat pretty much runs the show, sadly.
And yes, I *DO* run Xen at home, thank you very much!
Did El Reg really just bash somebody else for clickbait?!?!?
You CAN route IPX, although I feel sorry for the poor sod still using it!
"I can confidently predict the AT&T executives (and Time Warner ones too) will make whatever promises they're asked to.
Then they will go ahead and do whatever they were going to in the first place."
You forgot about the bribes, sorry, I mean "donations".
I love Slackware, I really do, but I moved to Void.
Tell fstab to not auto mount it and then mount it inside the init script once everything is up?
Sounds like the issue then isn't really atomic fragments, it's badly designed filters enabled by default.
"If there's no DHCP just hard code an address as per IP4". If you're talking about 169.254.0.0/16, then that IS link-local! Well, IPv4's version of it any ways.
WSUS Offline is nice, but for single systems try:
Semi-automatic, really. Fully automatic is very very pricey since you can only buy them if they were made before 1986. And yes, there's a big difference between the two.
XenServer is actually really nice!
"Well, I remember back in 1978 I proposed a Landsat for California ... they called me Governor Moonbeam because of that, so if they turn off the satellites, California will launch its own damn satellites."
Uh, no, that's not why at all:
The nickname was coined by Mike Royko, the famed Chicago columnist, who in 1976 said that Mr. Brown appeared to be attracting “the moonbeam vote,” which in Chicago political parlance meant young, idealistic and nontraditional.
Taxes in CA are already insanely high. Instead of expecting the state's taxpayers to pay for all of this themselves, surely it would make fiduciary sense to team up with ESA, JAXA, etc? It's not like NASA are the only ones with satellites that are studying the climate.
Not to be all pedantic, but the article says that bcrypt is "the best". While it's nice and all, Argon2 won the 2015 contest: https://en.wikipedia.org/wiki/Argon2
I admire and respect Vixie a LOT, he's a very sharp, very smart man. However calling him a security expert is kind of ironic, seeing that his BIND project has had a terrible security track record.
The sad thing is Intel inherited the old DEC Tulip network chips which worked damned well. No clue what they did to the technically to reach this state.
I had two Fortville-based XL710 cards and two previous gen X520 cards. The Fortville ones (post massive recall) still had major firmware bugs that caused them to pull the firmware with NO way to downgrade (the upgraded made a backup but no way to restore it!), and both had issues with SR-IOV and their own embedddd MAC filters. Trashed them and went with Chelsio and never looked back.
The better question is, do the keygens at least work, so that they at least get SOME positive out of this?
And surely any smart IT person runs a keygen in an isolated VM!
Actually is does SNMP perfectly well. In fact, as far as I can tell, unless you have the fancy education-only utilities, SNMP is the one way to pull a list of connected clients from the AirPort.
One thing that I loved about the AirPorts is that they simply worked pretty reliably. Most cheapo APs seem to need to be rebooted almost weekly. The AirPorts seem to just work, although I have heard complaints about the mDNS on it being buggy. I'd like to think that it being NetBSD powered helped the reliability.
Biting the hand that feeds IT © 1998–2017