My computer is in a data center where it belongs. My desktop is just a fancy terminal.

There is one disadvantage of the different ARM modes and that is the an arbitrary program will contain all the needed bit patters to make some useful code. This means that any reasonable large program will have enough code to support hacking techniques like Return Oriented Programming if another bug can be exploited. I would love to see some control bits that turn off the other modes.

Consider buying a new battery. Most laptop and cell phone batteries last between 200 and 400 charge cycles before their life gets too short.

If I compile from source, I can ensure that the binary I have is unlike any other in the world. That has protected my machines in the past so I will keep doing it.

Early Java was nothing other than a mess of pointers to pointers to pointers to pointers to more pointers all in a multi threaded system. The T1 addressed that problem but the concept of "All problems in computer science can be solved by another level of indirection*" is false and at some point compiler writers fix part of it. When they win, concepts like the T1 fail.

Sun tried great things with the T1 and it was like a great chess move that failed. The problem is they did a pawn sacrifice of their core business for that attack and it just didn't work out. Up until the T2000, Sun never designed their high end kit, they stayed with the low end and groups like Cray or SGI did their "big iron". The only great boxes sun designed in house where the small pizza boxes. The SS1, SSP20, x1, netra210 were great little servers. Things like the 690 and e10k were outsourced and while they were impressive as well, they didn't have the personality of the pizza boxes.

*To Quote David Wheeler

Have you read "man inittab" on any system V derived? action=respawn means it will ALWAYS run at the listed run levels. Sort of like how it runs the svc daemon does now. Whoever planned the new system just didn't get "init".

SMF only runs things as long as the contract system works.

As far as writing sensitive data to disks, do you know about the "real world?" Take a look at any online credit card system in the world. You will find people enter their card number as their email address, shipping address, reference number. You will find admins sending stuff like "can you fix 4111 1111 .... 1111 for me?" SSNs flow like water as well. Some times you must scrub the empty space on the disk or scrub stuff you know was just wrong. ZFS has NO ability to do that and that is a MAJOR FLAW!!!!!

ifconfig isn't about the stack. It is a tool to tell the stack what to do and has been for more than 3 decades. Inventing new tools to do the same job was pure incompetence.

No, the t2 can preserve the context of 64 threads but it can and will only run no more than 8 execution threads at a time. In most cases, the pipeline is so starved, it won't even manage 8. When it is running 8 at a time, it is doing each at a much slower rate that the older CPUs would be doing if they were made using the same process.

The II/IIi/IIIii can preserve something like 4 processes executions context at a time. Sometimes that is better. It is better on nearly all of my workloads.

Integer priorities mean I have absolute control.

The current system has no guarantee of any order of anything. This means if you get hacked at a non privileged user level, that process can hang around until it gets the "system is shutting down" signal, then do a quick fork/exec a few times and keep running until the system sends it a kill -9. Meanwhile it has a system without syslog running and without any auditing running. Take advantage of something running a broken xml library that runs setuid, and you own the system until it power off and nothing is logged at all.

What advances would that be? The ones out of Fujitsu? The T chips are just now catching up with workloads that they can run reasonably. I have work loads that a 15 year old Sparc IIi will out perform a few year old T2. The V100 was a $1000 appliance box yet the base T2 was selling for more than $6,000. If the UltraSparc IIIi was made at 22 nm (unlike its original 130 nm) and it would scream for most web appliance roles. It would even be a nice cpu for the Lights Out Management system and it could even run Solaris unlike their current LOM which is running Linux.

ZFS is on the right path but it still isn't quite where it needs to be. For example I can't tell it not to reallocate blocks on write so I can't force overwrites of sensitive data -- which is required in several industries that Sun used to be strong in. Someone in ZFS land needs to create an ioctl/fctl to fix that. The boot system also needs to be clear if it is trying to mount a ZFS or UFS disk since that is a bit tricky when the disk looks like both. They should also fix the fsck stub so it knows about ZFS and have a /usr/lib/zfs/fsck even if it is just a link to zfs status.

How is SMF better than init? They even bothered to break init so you can't pull SMF out the system if you don't want it. They now link init and smf to a number of libraries that have horrible security records. Do you want the main process in your system linking in libraries that need security updates on a monthly basis?

I know how SMF is worse, it is slower to start up, it is indeterminate in its start up state and order, it keeps its data in unauditable binary files an it takes far longer to shut down. It also isn't very good at what init was, which was making sure programs always ran. Solaris 11.1 turns off auditing, then syslog before killing off all user processes which means you have no idea what a rogue process did when it was told the system is shutting down. That appears to be a result of someone at Oracle deciding all the disks need to be mounted before starting syslog, which requires lots of extra crud to be running like NFS, RPC and whatever YP is called this decade and it appears that stuff is all trusted to shut down cleanly without the need of logging. At least with init, you could have two different syslog entries for the different run levels so you could make sure everything was logged and audited.

The number of bugs in Solaris 10 is far worse than Solaris 9. You can't build a light weight Solaris 10 or 11 system. Under 10, you could build a Solaris 9 container which would only run a bare number of processes but not any more since that feature was pulled out of 11. I have a number of Solaris 9 systems that are running less than a dozen packages but I'm one of the people who feel that if there isn't any unneeded software on a system, hackers can't use it hack the system.

Solaris 11 also has managed to break decades of sanity of using ifconfig to build network stacks. Now there are other tools that do part of the job and then can allow ificonfig to finish the job.

At least with Solaris 11.1 they created a tool to create smf xml files which means they are now no longer hand crafted which means a tool can be written to turn them back into rc.X scripts and they can be put back where they belong. Now if I could just remove svc.* without installing a fake to keep the contract open, I would be back up to the integrity level of a Solaris 9 system.

The 70's research brought us Lex and Yacc. Bison and Flex just carry on the traditions.

I think the subtletyâZ the objector had was that arrays and pointers are slightly different which is true In this context, an array is a pointer with potentially compiler allocated backing memory for the data while the pointer might not. A pointer will also have an address while the pointer used in array definitions won't have an address. Old compilers used to treat them identically but then again they used to treat pointers as integers as well. Modern compilers tend to know enough about the CPUs and have built in array checks that they do work slightly differently.

As I stated before. The chain of Zope that knows how to update the database is based on libraries that simply do not exist online.

The current Zope apps won't move to the newest version of Zope 2.x and there is seems to be no path from Zope 2.5.1 to the newer version while still allowing the existing code to function. There are major stumbling blocks from the days of the Zope 2/3 split and I suspect that code from before that is simply unmaintainable with any sort of reasonable budget. Our solution was to build an application firewall around the old code base and run it on its own isolated system. I'm open to having someone else try to move this to the modern era.

My concern is that I see this happening with all of our python based development projects as some coder imports a convenient library but that library is full of bugs or later fails to keep up with the new versions, we get locked into a maintenance nightmare. We don't see that nearly so much with C, perl or .net code. We don't see it at all on our embedded C / assembly projects. We did have the same problems in the past with DLLs and Borland C based packages.

We have a few applications written in zope. Zope was one of those classical python programs that needs a very specific set of libraries for each version of zope. Some of the required versions aren't even on the net any more according to google. At some point the Zope team split up and now the new zope won't do most of what the old zope was doing and the old zope has bugs and is a security risk and is now abandon-ware . So far we have hired 3 different python coders to "fix" the old applications yet none of them ever finished the job before moving on to other things. The odd thing is one of the zope applications was written in about a week the first time. So far our maintenance costs on it are about 1000% the development cost. That is the worst example, but the problem is endemic in the python community since nothing is every finished, everything is in a state of flux and your long term support options are based purely on some python coder not getting board and moving on to the new shiny stuff.