Re: Vax? VAX!
It's definitely and acronym. Virtual Address eXtension IIRC.
If it's been in storage, I would expect that it would take a while to get running again, and you wouldn't get any support from
Digial Compaq HP.
2490 posts • joined 15 Jun 2007
It's definitely and acronym. Virtual Address eXtension IIRC.
If it's been in storage, I would expect that it would take a while to get running again, and you wouldn't get any support from
Digial Compaq HP.
In the early '80s I built and ran a 'computer appreciation' lab at a UK Poly, back when computers were relatively rare things, and peripherals like robot arms, speech synthesisers, light pens, plotters etc. even more so. I do understand that physical things are more meaningful, but only for capturing initial interest.
Once the novelty wore off, the young people who 'got' what it was all about, the physical nature was less important, and those that didn't, it was no longer interesting.
In fact when given the opportunity to use any or all of this great kit in their end of year project, none of them were interested, and they all settled on pure software projects. Everybody involved in setting up and running the lab. were very disappointed.
I agree. I'm not making the comparison with the BBC micro, other people are. I just pointed out how stupid that comparison is.
Before this will be useful even as a wearable gadget, it will need a case, and some power. That will make it much more bulky, and mean there will be an additional outlay immediately before it can be used like this.
I can see a niche for it, but not as something given to 'every schoolchild' of a certain age, especially if all the majority do is connect it up to a PC running some cute development environment that allows it to display on the 5x5 LED grid a character moonwalking or dancing (Barclays are involved) at the click of a few on-screen buttons. Is that really going to be enough of an achievement to capture a child's long-term interest?
At best, it's going to be a novelty hook that may hold the attention of a small part of their target audience for long enough for them to learn something useful, but I fear that the number who take advantage will be tiny.
As is comparing it the the BBC Micro of old.
What made the BBC micro attractive was that it was a fully functional computer (of it's time) in it's own right, which you could start in a simple language drawing lines around the screen, making laser zap sounds, and have it prompt for the child's name, and then move on using the same system all the way through to structured programming, assembler, industrial control, simple office applications and data gathering and display. A cheap laptop with a suitable application is going to be far better.
This microbit is a toy that cannot exist without another computer being involved. It's going to be seen by the majority of kids as 'just another thing they plug into their PC with flashing lights' in the same vein as computer controlled toy missile launchers or bluetooth controlled RC cars. It will hold their attention for a few hours (if they get it working) and then be discarded.
I'm not saying that it will not get any traction. There are bright teachers (and some self-taught kids) who will do some tremendous things with it, I'm sure. Just don't expect this to be a significant part of teaching advanced computer interaction to the generation of kids who will receive it.
They'd do better going back to Logo controlled turtles, or a Kim-1 development kit.
The problem with young people is that they become older, and the political process takes time.
Take policies targeted at students. Most students of voting age are on 2 or 3 year courses, and have been since autumn last year. Any government elected in May this year will not be able to change policy this academic year, and probably will not manage it in the next either, meaning that it it would likely come in for the academic year starting September 2017. Any student in their second or third year will not be affected by any policies brought in by the next government so it is a waste of effort.
In addition, a government making new policies on, say student loans, will not change the conditions existing students, because that may materially change the affordability of being a student, and this is recognised as being unfair.
It's difficult getting young people to engage. My four kids (ages 19-29) are all registered to vote, but I suspect that none of them will, not because they are apathetic, but because they have not yet learned enough about life to be able to identify what will affect them in the future. And I think my kids are of at least average intelligence.
They just do not follow what is happening in the country or the wider world, and they don't trust (probably wisely) the spoon-fed election propaganda from the politicians, as they realise that this is just a sop. I keep getting asked what my views are, and being a of a liberal (note the small L), I don't what to influence them with my thinking too much.
I did not mention hamming codes, because I learned about it over 30 years ago (it was one of the first things taught on my CS course at uni.), and I was not certain the term was in use still, and I could not be arsed to spend any time reading up on the specific techniques used nowadays while writing the comment.
If you could predictably determine which bits would be flipped, you may be able to do this, but most ECC memory has multiple bits for error correction per 64 or 128 bit word, and use something a bit more sophisticated than plain parity.. The ECC I've seen normally allows single or double bit corruption per word to be fixed, with multi-bit corruption detected. You would have to be able to flip the bits in a pattern where the ECC bits would not flag an error, and in order to do this, you would need to know how the ECC bits are calculated, which is probably memory vendor specific.
I don't know how Linux handles uncorrectable ECC errors, but other OSs normally take exception, and depending on what was running at the time the ECC error occurred would either kill the process, or if it were in Kernel mode, panic the kernel. I've even seen this take out an entire system running VMs in a type 1 hypervisor, if the error occurs while executing hypervisor code.
As a result, if you are using ECC memory, you would have to get a correct pattern every time or else things will happen that will be noticed.
I was initially sceptical about this because I could not see how you could predict which other memory pages would be affected by a particular rowhammer, but the report adds much detail to the issue. If you are really interested, give it a read,
There is quite a lot of "Hopefully this..." type of statement, so the authors acknowledge a degree of luck in triggering the exploit.
The report also acknowledges that the exploit will work best on a system that is fairly idle, as it requires the process to essentially fill all of the available memory first with known data to identify related memory pages, and then with page table entries created using mmap().
In a machine with other workload, the likelihood of being able to control enough memory to allow this to be reliable is seriously reduced (it requires a page that is identified, then freed to be immediately used by the system for a page table page, something that could not be guaranteed on a busier system, especially as the page freed with madvise() + MADV_DONTNEED would probably generate a context switch).
All the time you are rowhammering essentially unpredictable pages (part of the exploit is to hammer memory lines until you can find one that affects a memory page you control), you could also be creating other problems on the system including unpredictably modifying running code and data structures.
The more you have to do this, the more likely it is that you will trigger another unpredictable action which would attract attention.
There is also tacit acknowledgement that this attack in it's published form relies on certain features of the Intel x86-64 architecture (specific instructions to allow rapid toggling of memory bypassing the cache like CLFLUSH), although it does suggest ways of triggering the bit flip on other architectures.
Don't get me wrong. It's a clear issue, and one that is exacerbated by the fact that Linux, being open, is less difficult to craft an exploit for because the internals are better understood, but I believe that exploits in the wild are likely to be few.
I would imagine that she has 'satff' to do it for her. All she had to do was make sure they were paid, and that was probably being done by someone else anyway.
The convenience was only having to carry around one device, with one account on automatic login.
Well, someone had to say it, and unusually, I had the chance to be the first.
Cleverness is relative. I only claim to be a Register reader for some years, not that I am particularly 'clever' or 'bright', although I do value my silver badge. IMHO, this type of article is poor compared to previous articles, so I was commenting on whether the type of reader The Register is attracting is going down.
And they let you attach USB memory devices that had been used on non-secure systems?
Goodness, how lax!
This article does not appear to be aimed at the traditional Register reader.
Add to that the fact that it is proselytizing cloudy services means that it is, IMHO, a below par article.
Is it really the case that we now have people who could derive benefit from this type of overview article reading the Register? If so, I need to find another site to get my tech. news.
All good points... provided that the SLA with their customers reflects a realistic amount of downtime for the service. I've been involved in implementing services that are designed to be able to cope with failures, and this is what I feel the cloud providers should be aiming at.
The problem as I see it is that cloud providers sell their service as resilient ("just look at all the places we can move your services to"), giving customers an expectation, without actually investing in the infrastructure that actually allows this expectation to be achieved.
Cost is an issue, of course. Cloud providers must match a realistic expectation of total system availability with the cost, with different tiers of pricing. Otherwise, providing cloud services will become, in a currently popular phrase, a race to the bottom, with price being the ultimate factor in the choice.
Unfortunately, the people buying the service may not actually really understand what they are being sold, and if someone with real experience of service continuity tries to point out the deficiencies, they will be branded alarmist, or protectionist (of their own jobs), and be sidelined.
... the outage did not affect the whole of the GCN, just parts of it.
If it did affect it all, then it would appear to be that they've got at least one too many single points of failure.
Whilst I know that certain parts of the core infrastructure are difficult to make completely redundant, multiple network fabrics that can be run in isolation for resilience is not a new idea, nor is only working on one of your fabrics at once a particularly taxing notion.
I feel that all cloud providers should effectively have the best High Availability features for their infrastructure. Don't rely on the MTBF figures provided by your equipment suppliers to be a realistic figure for the availability of the service run on the kit, because unexpected 'stuff' happens.
I mentioned Raspberry Pi, because I happen to have a B+ sitting around not doing a lot at the moment. For me, it's all about not spending too much money.
My VDSL sync speed to the exchange is around 80Mb/s, and I have managed to get speed tests of ~50Mb/s when directly connected via GigE to the router, so I am a little uncertain that USB2 connected Ethernet adapters (theoretically capable of connection at the required speeds, but I' always sceptical) can hack it.
I've just scavanged a newer old laptop back from one of the kids (they weren't using it as it would not game), and am going to try a firewall distro that supports Cardbus with a 1GB Cardbus Ethernet card that I have lying about. IPFire looks like a suitable distro.
Yes, I meant Raspberry Pi.
The problem is that I don't want to spend too much (any?) money (you can call me a skinflint if you like, I won't take exception). I've got used to using otherwise discarded kit (It's a Thinkpad T20 at the moment) for my firewall, and it's got to the point where I don't actually really have anything powerful enough to comfortably do this job without having to resort to a re-purposed deskside machine. Being a full-time Linux user, I'm still finding my go-to Thinkpad T43 good enough with Ubuntu 14.04 (LTS with Gnome-fallback), and have not had to buy a more modern laptop to free up anything remotely powerful.
I've now actually looked at IPFire on Intel processors, and it may actually be good enough with the current laptop I'm using as a firewall, when used with a PC-Card ethernet device. This is where Smoothwall was lacking, it didn't support PC-Card devices without serious modification, involving a modified kernel - the stock kernel does not support PC-Card modules.
But I then have the problem that the best Wireless Access Point I have (in the Bright Box) is outside of the firewall!
There used to be single function devices that took a Ethernet (or USB) on one side, and an DSL link of some sort on the other. They allowed you to use PPPoE on another device (firewall or computer) directly to whatever was in the exchange. There was no 'routing' done in the device at all. You might have called them 'repeaters' or bridges, although both of those names have fallen into disuse. These devices could not remotely be called routers, although modem would not really be accurate either, but was a common term used.
Some ADSL routers could operate in bridge mode, doing the same, and not actually offering any IP routing. This may still be possible, I've not looked recently.
But nowadays, what you get is a multi-function device that does lots of things including routing, wireless access, firewall, DHCP, VPN and in some cases print and filesharing, and this is one angle of the story, that the more function you build into a device, the more likely it is to have a security vulnerability.
Before I had FTTC installed, I used to have an ADSL router connected to the Smoothwall firewall "Red" network, and all other comms kit on the "Green" network, including the wireless router(s), powerline Ethernet and all the systems.
My wife, looking at the pile of 'things' next to the 'phone line always complained about the space and power (really), and whenever we had an interruption to the Internet, always blamed it on the fact that we did not do it the same as everyone else, even though she has no more idea of comms and security than a potato.
Unfortunately, and to my shame, I've had to drop the idea of running a separate firewall. The hardware I have available just can't keep up with the speed of the network, and having just a single box powered on all the time appears quite attractive at the moment.
I need to spend some real money sometime! Anybody know if IPFire for a RiPi is any good?
I know this. That's why I know that AC comments appear on "My Posts". What you don't know is how many of my comments are posted under my name, and how many are anonymous!
As there is no HTTPS offering, you or any other boss (or your network specialists running the firewall(s)) could examine any postings made from inside your company (or even on the "Dirty" wireless network that you offer to your employees) without any difficulty at all. So it's not even protecting people from their bosses!
What I was trying to say is that in terms of anonymity to the security services or the Register staff, the AC box has no meaning.
Stating the bloody obvious here. Posting as an anonymous coward here does not make the comment truly anonymous. All it does is make it so other readers cannot see who who posted it.
In order to post a comment, any comment, you have to be logged in. Even if you click the "Post anonymously" box, the comment is still recorded against your ID. Just look in your "My Posts". So anybody in El. Reg. can tie any comment to the email address registered against the account.
Anybody who really thinks that they are anonymous just by clicking the box is deluding themselves, as I'm sure everyone here knows.
Deduplication is fine if your data contains significant amounts of duplicated data.
Where I work at the moment, we generate 6-8TB of UNIQUE data (scientific data collected from the wild plus results of modelling derived from that data) that needs backing up (via incremental forever) every day.
It's relatively compressible, and TSM compresses the 6-8TB down to 2-3 tapes worth (1TB uncompressed tapes), but I would be very surprised if there is much at the block level that is duplicated, and less at a file level.
For this type of data, cloud backup is really not an option, and cloud storage does not work because of bandwidth issues. Powerful though the collective resources of your cloud provider are, they don't match the requirements of HPC workloads.
Plymouth had an airport. It just didn't have passengers wanting to use it.
Unfortunately, the market will ultimately dictate whether an airport is viable, and it looks like Plymouth wasn't.
I'm not sure whether Newquay is viable, either.
You have no idea how ironic it is that I forgot to include the Met Office!
Well, not strictly true.
You've got Plymouth Dockyards, RNAS Yeovilton, and the UK Hydrographic Office which are directly MOD or MOD trading funds, so west of Bristol is too broad.
But Cornwall? Isn't that a different country! It certainly feels like it sometimes. I mean, for some time last year, there was not even a mainline railway running to it!
I had a colleague who used to work on TV and monitor design. He said that the automatic degaussing circuit that used a PTC thermistor often drew up to 100A from the mains. The only reason it did not trip the breaker or fuse on the ring main was because it only drew that amount of current for a fraction of a second, less time than it took the breaker (or a fuse) to operate.
I had no reason to disbelieve him.
I also know that when I worked for a big bank, if the power went out on the floor I was on, we were told to turn off all the large CRT monitors before they resumed the power because the degauss surge on so many monitors at the same time would throw the breaker again as soon as it was operated. Apparently, although the building was designed with computers in mind, the architects did not expect the large CRTs that support people asked for. As a result, the floor rings were right at the safe limit under normal operation.
That floor was the first to get flat panel LCD monitors when the refresh happened.
Degaussing circuits were not in late '60s and early '70s valve TVs. These would often, over time, acquire a permanent magnetic field around the chassis or the tube itself, leading to psychedelic colours at the edges of the screen. You got a TV engineer out with a magical degauss coil that he waved over the screen to make it work properly.
To compensate for the earth's magnetic field, these TVs actually had small bar magnets mounted on the chassis around the tube on bendable 'stalks'. These would be painstakingly adjusted until the Test Card showed no distortion.
My mother was obsessed with keeping a cabinet TV. They used to rent a Baird from Radio Rentals right from when BBC 2 first started transmitting in colour (around 1967 IIRC - That was a bad year for me because of illness, and I was off school for some time, and I got hooked on the Trade test transmissions which were broadcast on the hour for the benefit of TV installers - White Horses, Skycrane, and trout farming come to mind). Towards the end of it's life in the '80s, the tube was so badly magnetized that it would not demagnetize, no matter how many times the degauss coil was passed over the TV. Of course, it could be that Radio Rentals no longer had any working degauss coils in their toolboxes!
Eventually, Radio Rentals pleaded with my parents to stop calling in faults and let them take it away, because they could no longer fix it. They provided a Ferguson in it's place, which just did not hack it with my mother as it was made from paper covered chipboard, rather than real wood!
Right up until the end of her life, my mother still complained that the sound and colour(maybe because it was not psychedelic!) of whatever TV they had was poor compared to the Baird TV. I think it was an ideological thing, however, as this was even with the sound passed through external amplification.
It is entirely possible that it could be done as a community project, but the resource involved would probably be too much for a one-man band, or even a small group of people doing it in their spare time, and the necessity to test it against the plethora of distros would be a similarly mammoth task.
It's easy to have a community project that adds a veneer over the top, because you can break the tool down into modules that drive the documented tools. Getting in at the fundamental layers, where the different disros tend to differ from each other, and where the documentation has not been maintained, or in some cases not even written is a much harder task, and requires much more research and testing.
It would be difficult to get such a layer accepted to the extent that the major distro owners would adopt and maintain this common approach in preference to their own distro specific tool.
If we had had a situation where a fully free Linux had become a defacto standard, then if that distro maintainer was altruistic, they could have incorporated something like this and hope that it would be picked up by other distros, but it seems unlikely that the increasingly fragmented Linux world will settle on a dominant distro (hell, the systemd risks fracturing the community even more than it currently is).
What with Canonical, a company that was being portrayed as a bit of a white knight a few years back, going in a direction that is unlikely to be followed by other distros, I think the time for a dominant distro is fading into the past. Mint is unfortunately reliant on Ubuntu, and RedHat always had an agenda to try to leverage support contracts from their users. SuSE, which looked like it's independence was under threat appears to have weathered the storm but has lost followers. Debian appears to be going with systemd, which will alienate a lot of people (and will be a nightmare to administer using a tool such as I am proposing).
I suppose that Lennart Poettering (systemd) could take on an administration tool that would plug into systemd and extend it to cover other sysadmin tasks, but I for one would not trust him to run such a project without making it almost completely unusable/unsupportable.
System administration is one of those areas where Linux has suffered because of the diversity of the distros.
The one-size-fits-all processes like useradd will do the basic job at hand on the local system, and are pretty similar across all versions of Linux. Once you get beyond this, each of the distros have their own idea of how to streamline this and other admin tasks, and most of these are pretty distro specific. In some cases they are proprietary and closed source to try and generate a revenue stream, and do not interoperate.
There is not even a consistent package management format across all versions of Linux.
It is very difficult for a new Open Source package to come along and streamline this. What is needed is a low-level tool that goes in at a suitable level so that it can manipulate the configuration files/databases/objects fundamental in Linux, to provide a consistent system management layer in all distros .
What you actually get (like with Puppet) is a whole load of distro specific methods layered on top of and driving the specific interfaces for each distro. This works, but is high maintenance, which often means that it becomes paid-for software (again, Puppet is an example of this).
There are two ways this could happen. One is if the major distros decide to collaborate and produce a common administration interface. The other is for a standardisation body to add the specification of such an interface, and have the distros adopt that standard.
The former is unlikely to happen, as the distro specific sysadmin stuff is where people like RedHat and Canonical make some of their money. The latter cannot happen as there is no accepted Linux standard or even standardisation authority, and even if there were, it would be dominated by the commercial distro maintainers, because they are the only people who might have resources to invest in a standard, and then we are back to the former point.
So what we have left is paid-for software or home-grown scripts put together by sysadmins which do the job, but are seen as being messy.
I can see no way of moving this forward unless someone with big pockets and a lot of influence with the distro maintainers decides to take it on.
I think that all the time there are native people with relevant skills available, that this type of request should be squashed. Does the Government even try to assess whether there is a real skills shortage, or do they trust the very people who are asking and would likely benefit through smaller wage bills?
How to independently measure whether there are people available to do the jobs? Well, how about a Register!
Anybody in El. Reg interested in creating a list of people with specific job skills who are currently available to present to the Government to counter claims of shortage of skills? I'd probably be prepared to pay a reasonable amount to appear on such a list when I'm not in work!
I've used the Joke icon because of the pun, but maybe it's not a joke.
Unless I've missed something here, the steps of forking another process and performing a setuid/seteuid are still separate calls. It's not the fork() that is the problem, it is the fact that in order to perform the setuid/seteuid() the process changing it's credentials must be running as root.
So you have a root owned samba process that forks another root owned samba process, which then changes it's credentials to the user.
This is the way it works for all traditional UNIX processes first acquire a users credentials, things like login, sshd, telnetd, ftpd etc. etc. As people point out, it is a fundamental feature/flaw depending on how you look at it.
This is changed significantly if SELinux is turned on (or another RBAC system on other UNIXes), whereby you need to have the correct roles assigned to a process for it to be able to perform actions, which includes syscalls. Thus, I think that Linux already has a more controllable authentication system, it's just not turned on in most systems, as it's foreign to the way that most Linux/UNIX systadmins think.
Even though I understand the concept. I'm one of the sysadmins who've never set up a RBAC/SELinux system in anger, so I still have to go through the learning curve for this.
You reverse engineer an existing Word document to work out how to use Word!
I would say that this is close to an impossibility, especially using styles as an example.
I've seen Word documents that have dozens of what look like identically names styles, caused by someone tweaking a particular element in a paragraph (like indenting it), which leads to a new modified style being created with the same or a very similar name.
I once spent the best part of a week cleaning up a long, operational document that had been pieced together by cut-and-paste from other documents which had something like 100 different styles in it. All of the source documents were supposed to have been written using the same template, but a lot had had the styles changed in minor ways at the whim of the author. And Word kept the modified styles when doing cut-and-paste!
I'm a real throwback. I did most of my technical writing in the past in troff with memorandum macros, and I used to use SCCS as the change control (and make to control the whole process). I suppose if I was writing more than I do at the moment, I would probably take a similar tack with LaTeX and a modern change control package, although I do find for my purposes Git or Subversion are too complex. As it is, for short documents and letters, I tend to use Libre all the time, because I can pretty much guarantee that it is either already available or can be installed. Such is the advantage of free software.
The difference is that if an in-house service goes down, you can investigate the problem after the fact, and try to so something to prevent that same problem from happening again, and this includes disciplining anybody responsible for the design or operation of the service.
You have nothing like that level of control with cloud services. You might hope that the service provider may learn from the experience and do the same type of review that you might, but there is probably nothing in your contract that forces them to do so, and this probably includes actually being given an accurate and complete report of the issue. Unless there are specific uptime targets in your contract, it may ultimately be that the only lever you have over the provider is to threaten to leave them, with whatever the fallout that will cause.
I don't doubt that there are some services where this is a perfectly acceptable risk, but there are many, many others where this is just not the case. Couple that with the uncertainty regarding control of access to your data, and these things together make it quite unlikely that I would recommend putting any business critical service in the cloud.
"That's like claiming IE stats don't count because Microsoft got the original code from Spyglass.."
Um. No. It's really not.
Red Hat do not 'own' all of the packages. They do not claim that they maintain all of the packages. You are falling into the same trap that I showed was false in a previous post. Please refer to that.
But to re-iterate. Red Hat own the compilation and packaging of many of the packages in their repositories. They do not own the maintenance of the packages themselves. They could fork a package if they wanted (it's Open Source after all), but in most cases they don't want to for perfectly valid reasons. Use Firefox as an example, which is in the distro, but is maintained by the Mozilla Foundation.
In contrast, Microsoft claim IE as their own package. They maintain it. They employ staff explicitly to maintain it, and they would be super-pissed if someone else tried to publish a derivative of IE, or claim some IP over it.
It appears to me that you are deliberately trying to confuse the issue, unless you really have a fundamental mental block about what Open Source is all about.
It seems to me that several of the distros include packages like Asterisk and Sems in their repositories, and Glassfish/Sailfin appear to be Open Source packages shipped as jar files that will not need compiling. Now I don't know what you were trying to achieve, but did you look?
I realise that you may have been wanting features that are not in builds of packages in the repositories, particularly if you want interoperability with some commercial products (vendors just love to include proprietary or bleeding edge extensions which often cause problems with Open Source packages).
If the package you were wanting was part of a commercial product, even if it were a free component, then did you try suggesting that the vendor provide the same degree of support for OSs other than Windows as they do for Windows? Sometimes what people see as a deficiency in Linux is really with the vendor of a particular package being unwilling to provide adequate support for Linux platforms, and that is hardly the fault of the distro maintainer, or the Linux community as a whole!
Don't for a second think that ACLs are a feature introduced by Windows.
The earliest I remember ACLs being discussed was in Multics, whose design goes back to the 1960's, before Microsoft was even a company. Multics had a very complete security model for it's time, which included control over processes and services as well as the filesystem.
The thing about UNIX-like file permissions is that they have been good enough for most purposes for decades. They're a long way from being perfect, and I've said as much many times on these forums, but they can be made to do most of what is required with the right amount of knowledge. This has meant that until recently there was no pressing need to implement ACLs.
Where they were implemented, they were frequently unused because system administrators of the time did not think it necessary. Simpler times, maybe.
ACL implementations have existed in UNIX systems for many, many years. They first appeared in AIX with AIX 3.1 in 1990, and I'm pretty sure that the Veritas filesystem that could be used as the base filesystem on a number of proprietary operating systems also included ACLs.
The Andrew File System had both Kerberos support and ACLs from the early 1990's as well.
If you think that filesystem ACLs are not enough, look at the UNIX and Linux implementations of RBAC (and SELinux). Because most RBAC implementations use PAM, this means that it is possible to have RBAC controlled by Kerberos, and even put LDAP in the mix, and this allows something not that dissimilar to what I read Windows can do. And this has been possible for many years, before Microsoft jumped on the Kerberos bandwagon.
It is perfectly possible to use Kerberos to control access to a Linux system. All distros I know ship a PAM (Pluggable Authentication Module) which allows you to use Kerberos as a primary access control mechanism. OpenSSH has Kerberos support built in, and there is support for Kerberos tickets in sudo to control user commands.
Many years ago (~20 IIRC - before even NTFS 5 and Windows 2000), there was a file system called DCE/DFS for POSIX'y systems that also integrated Kerberos tickets into filesystem ACLs. The Andrew File System (which DCE/DFS was adapted from) still exists and still uses Kerberos tickets to control access. Generally speaking, it's a technology that was regarded as unnecessary, or maybe it was just ahead of it's time. I think that GPFS can also use Kerberos, but that may just be for system-to-system authentication. Thinking about it NFS4 and later uses GSSAPI, and you can plug Kerberos into that as well.
So don't think that Microsoft invented these things in Windows. They're playing catchup, but no doubt they will try embrace, extend and extinguish again as they have tried with LDAP/Active Directory and DNS.
Having just read a Technet description of Kerberos constrained delegation, it would appear that Microsoft have implemented a service using a fundamental feature of Kerberos - which appeared on a number of platforms including UNIX before it was added to Windows, and have been presumptuous enough to have given it a name.
Linux implementations of Kerberos will have the same fundamental technologies, but nobody has given it s specific name except Microsoft, who are trying to cash in on other people's work. I'm pretty certain that all Linux distro's will have Kerberos 5 support in their repositories. RHEL6.5 certainly has.
There are also several deduplication facilities available for Linux, including a number of filesystems like btrfs and ZFS. You just have to use a search engine to find them. ZFS also supports tiered storage (before Windows 2012, btw), as does IBM Elastic Storage, although Elastic Storage (aka GPFS) is commercial software.
I admit that it's not out-of-the-box, but it's hardly difficult to come by.
There always were different ranges of Thinkpads.
Go for the T series (or an X series if you want a compact laptop).
When IBM owned the brand there were at least the R series which were plasticky, and the A series which were larger and heavier. Before that, they were numbered, with the 300 range being budget and made of plastic, and the 700 range being the business systems.
Lenovo have dropped all of the old IBM ranges except the T and X, and have re-branded some of their other ranges as Thinkpads to cash in on the name.
I have a work T420, and apart from the appalling new 'island' keys, it seems as robust as the older systems.
The T used to stand for Titanium (actually an alloy with titanium in it) that was used in a chassis to stiffen the screen/lid, which along with clever interlocks between the lid and base led to the reputation about them being extremely robust. The hinges certainly last longer than most other laptops.
This was not just an Expanded Universe story. It's THE FIRST Expanded Universe story.
It was published before The Empire Strikes Back was released, so is extremely non-canon.
Got to have a GITS SAC reference here.
Stand infiltration technique. Hack their eyes so they can't see you.
"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - JD Salinger
"Or should I" - Laughing man!
It all depends.
If the web-site designers have loaded it with copious numbers of large images, it may actually not be possible to use dial up, at least not if you intend to maintain your sanity.
I've not seen the Verify web site, so I can't say for certain how heavy that page is.
From my perspective, there are basically two different types of farm. Large ones, run by technically capable farmers, and small mainly family run farms that may be years behind in the deployment of technology. I have both types in my extended family, and have had to help my father-in-law comply with some of the demands made of them in the past, as even something like deciding what the map reference and acreage of a field is can be a challenge. My father-in-law before he gave up farming would have no idea about how to verify his ID using a service like this. He would rely on a professional like an accountant or other professional to do it for him, like he did with his tax, VAT, and to some extent his subsidiary paperwork. If that avenue was not open, he would have left farming earlier, like so many others.
It may actually be the case that using a relatively technically challenged group is a good one to test the system out with, but you'd better make sure that there is an emergency catch-net, because in the case of some farms, the EU subsidy is all that separates break-even from loss, and I'm not sure that the banks are compassionate enough to refrain from taking action if loan or other payments are not made because the subsidy payment is delayed.
We need a technology that can be abandoned and still be readable in future times.
Any technological solution is bound to fail because maintaining it requires repeated investment in either maintaining what will become an obsolete storage format in the future, or repeatedly re-writing it as new media are invented.
It's all very well suggesting that technology from people such as "Carnegie Mellon University and IBM Research" might be worth using, but this assumes a certain amount of continuity to maintain the physical storage that requires organisations to survive. You cannot rely on government or industry to still be around in the future, and the 'Cloud' (whatever is meant by that) needs to be maintained as well.
You end up with stupid chicken-and-egg situations if the description of the programs and machines necessary to read the media is only stored on the media itself.
I respect Vint Cerf. He's very influential. But he's not, in the grand scheme of things, an engineer (his degrees are in Mathematics, and he's managed various teams and companies mainly on data communication). Nowadays, he's good at the grand scheme thinking, not the detail.
He was being interviewed on Radio 4 this morning, and I got the feeling that he was either dumbing down what he was saying for a non-technical audience, or that he did not fully understand various fundamentals on machine architecture and what would be necessary to maintain in order to run a program from a current generation of machines. I would hope that it was the former, but I was not convinced. When taking about the systems, he talked about taking a snapshot of the software "with a description of the machine it runs on", glossing over that the description would have to be incredibly detailed to capture all the nuances of machine architecture to allow a working machine to be reconstructed from that description.
I would suspect strongly that it would already be nigh on impossible already to reconstruct systems from people like DG, Prime or Tandem (amongst others) unless working physical instances exist.
Trying to capture all of the operating characteristics of a complex modern processor like Power 8 or a Haswell and the associated support chipsets to allow it to be reimplemented in the future on architectures unimaginable at the moment would be a herculean task!
Much better would be to ban the use of all proprietary closed file formats, and keep the definition of the open file formats in enough detail to reconstruct the data stored in those formats.
But this does not alter the fact that there needs to be readable media maintained in perpetuity.
The bidding process itself is enough to put most SMEs off.
The time and the cost is just not something that a company that does not turn over millions can risk without some expectation that they could get the contract.
...and stored on recordable optical media for longevity!
I think 5.25" floppy disk was a flawed media anyway.
You relied on the disk remaining flexible enough to spin in the case which was not flat, stiff enough to not crease while it was being spun up and moved over the heads, and for the glue to remain stable enough to keep the rust particles attached to the disk while it was scoured by the disk head and the 'soft' material on the inside of the case. And you also have the problem of the way that the clamp on the drive grabbed the plastic of the disk itself, and over time damaged the edge of the hole.
From my experience, all 8" and 5.25" floppies ware now of questionable use, regardless of manufacturer. Certainly, I have Verbatim disks that still read, and BASF, Nashua and 3M disks that don't.
The 3.5" and 3" disks were slightly better because at least the case was rigid, and was less likely to rub the surface of the disk while it rotated.
Optical disks are much less likely to suffer, because there is significantly less physical contact (ideally none) anywhere on the disk except where the clamp grabs the disk. I have 30 year old audio CDs that still play, and some CD-R disks that I recorded before the millennium that still can be read.
My personal feeling is that if the media is rated for that long, there will be some effort made to make sure that, at least in the medium term, that the media can be read.
Couple this with the fact that it is piggy-backing on a consumer level technology, and should be able to be read on any BD-XL drive means that there is a higher chance that devices will continue to be made into the near future (decades) that will read it. I know that it is not really a good comparison, but CDs are still readable in current generation BluRay readers, so that shows that a medium with sufficient market penetration can still be readable nearly four decades later.
I know that this is not anything like the 1000 years specified for this media, but it is suitable for medium term (decades) archive of financial data in a way that current generations of disk/tape technology is not.
I'm not going to suggest that we should stop using durable physical media for the intelectual riches of our society, however, because when the technology fall happens, anything that is not readable by eye will be useless anyway!
And do what, once they are out of the seat?
Have you actually tried to do anything using just the minimal set of buttons on the telly itself?
You're normally limited to buttons for power, channel up and down and volume up and down. If you're lucky you may have an input selector and sometimes a menu button. And if you're really lucky, there may be a physical power switch somewhere you can find it.
Whilst checking a Sharp telly I was given (without a remote), I tried to get it to re-scan the DTV channels after I had done a reset. Turns out you can't do it at all without the remote. Fortunately, I came across a code for one of my universal remotes that provided the "DTV menu" button needed. I also think that my main living room telly can't select HDMI as an input from the buttons on the telly.
Somewhere in the house I have a Maplin catalogue from about 1981. I know that this is a few years after they started (I first ordered from them in about 1976, but from an advert in ETI). This was the time that Radio Spares and Farnell would not sell to you unless you has a business account.
I'm pretty certain that even back then they sold gadgets and gimmicks like RC cars, clocks et. al. There just weren't as many things available (remember that back then, digital watches were a pretty neat idea), and basic things like digital multimeters, calculators, breadboards with TTL and LEDS and electronic ignition modules satisfied the techno-lust of the geeks of the day, and other men (sorry, the time was just more sexist) wanted motorbikes, powerful cars and season tickets to their football team.