• SHINC: Sundays and holidays included
• SHEX: SHINC plus a dollar
• CQD: SHINC plus five dollars
• BOOKING NOTE: Gencon plus ten dollars bends
• CENTROCON LOAD: A technical term for robbery
• GROSS LOAD: SHINC plus your grandmother’s age, but you won’t get it
• MECH LOAD: Similar to Centrocon load but less owner friendly. Alt. Theft"
• WEATHER WORKING DAYS –CQD: plus four days (eight if grain)
• HSS: Heavy grains, Soya, Sorghum
• WHEAT: HSS less fifty cents
• BARLEY: WHEAT with hair
• "LIGHTS": A term for grain houses to use in order to lie about what they paid for HSS
• MILLET: Wheat for poor people and budgies
• TANKERS: Gearless vessels with no hatches
• MILO: Who knows?
got from this link:
http://virtualshipbroker.blogspot.com/2010/02/excellent-commercial-question-from.html
by: Suraz said...
Wednesday, November 30, 2011
Monday, November 21, 2011
Splunk Log Management
Here is the example of logging using Splunk.
(Splunk is enterprise software used to monitor, report and analyze the machine data produced by the applications, systems and infrastructure that run a business,http://en.wikipedia.org/wiki/Splunk.)
I am running Solaris
bash-3.00# uname -a
SunOS atlas.haritamineral.com 5.10 Generic_141445-09 i86pc i386 i86pc
bash-3.00#
Using syslog for logging jetty log.
The configuration of log4j.properties looks like:
log4j.rootCategory=INFO, CONSOLE, LOGFILE, SYSLOG
log4j.appender.SYSLOG=org.apache.log4j.net.SyslogAppender
log4j.appender.SYSLOG.Threshold=INFO
log4j.appender.SYSLOG.Target=com.haritamineral
log4j.appender.SYSLOG.layout=org.apache.log4j.PatternLayout
log4j.appender.SYSLOG.layout.ConversionPattern=%d{dd/MMM/yy HH:mm:ss} %5p %t %c{1}:%L - %m%n
log4j.appender.SYSLOG.SyslogHost=localhost
log4j.appender.SYSLOG.Facility=Local2
log4j.appender.SYSLOG.FacilityPrinting=true
and the syslog.conf in /etc
I Just add one line
#jetty
local2.info @master.haritamineral.com
Where is master.haritamineral.com is splunk server that listen logging UDP and TCP running on port 514.
for restart, disable, enable the syslog is using svcadm command.
#svcadm restart system-log
First try, I am getting error :
Nov 21 14:34:25 atlas.haritamineral.com syslogd: line 20: unknown priority name
After googling, that my mistakes is using of space instead of TAB key.
as you can see you can see my log4j in my jetty applications in Splunk Log Management.
(Splunk is enterprise software used to monitor, report and analyze the machine data produced by the applications, systems and infrastructure that run a business,http://en.wikipedia.org/wiki/Splunk.)
I am running Solaris
bash-3.00# uname -a
SunOS atlas.haritamineral.com 5.10 Generic_141445-09 i86pc i386 i86pc
bash-3.00#
Using syslog for logging jetty log.
The configuration of log4j.properties looks like:
log4j.rootCategory=INFO, CONSOLE, LOGFILE, SYSLOG
log4j.appender.SYSLOG=org.apache.log4j.net.SyslogAppender
log4j.appender.SYSLOG.Threshold=INFO
log4j.appender.SYSLOG.Target=com.haritamineral
log4j.appender.SYSLOG.layout=org.apache.log4j.PatternLayout
log4j.appender.SYSLOG.layout.ConversionPattern=%d{dd/MMM/yy HH:mm:ss} %5p %t %c{1}:%L - %m%n
log4j.appender.SYSLOG.SyslogHost=localhost
log4j.appender.SYSLOG.Facility=Local2
log4j.appender.SYSLOG.FacilityPrinting=true
and the syslog.conf in /etc
I Just add one line
#jetty
local2.info @master.haritamineral.com
Where is master.haritamineral.com is splunk server that listen logging UDP and TCP running on port 514.
for restart, disable, enable the syslog is using svcadm command.
#svcadm restart system-log
First try, I am getting error :
Nov 21 14:34:25 atlas.haritamineral.com syslogd: line 20: unknown priority name
After googling, that my mistakes is using of space instead of TAB key.
as you can see you can see my log4j in my jetty applications in Splunk Log Management.
Monday, January 3, 2011
Is Data ONTAP Based On UNIX?
Is Data ONTAP Based On UNIX?
A customer recently asked, “Is Data ONTAP based on UNIX?” Complicated question.
The first version of Data ONTAP borrowed lots of code from Berkeley Net/2 (one of the earliest open-source releases of UNIX), including the TCP/IP stack, system boot code, and device drivers. Since then, we’ve borrowed liberally from other open-source UNIX releases. We wrote the command line interface from scratch, but we designed it to look like UNIX, since our first market was UNIX system administrators. Clearly, ONTAP is related to UNIX.
On the other hand, ONTAP’s architecture is very different from UNIX. There is no user-space, the filesystem is completely different, the RAID and diskubsystems are completely different and most important of all, the interaction between subsystems is very different. The key data paths from network to disk look nothing at all like UNIX.
You can imagine two completely different ways of building an appliance. You could start with UNIX and strip out, disable, or hide the pieces you don’t want. sOr else you could start from scratch, inventing a new architecture optimized for the task at hand, but borrowing liberally from the UNIX code-base as appropriate. We chose the latter.
Interestingly, our advanced ONTAP GX architecture is built on top of a full UNIX release. We took Data ONTAP, including WAFL and RAID, combined it with the new code from our Spinnaker acquisition, and hosted the combined result on FreeBSD in a combination of user processes and kernel modules. For security and simplicity we have disabled and hidden many parts of FreeBSD.
Even for ONTAP GX, this isn’t quite the “start with UNIX and slim it down” approach, because most of the system lives in large kernel modules that kick UNIX out of the way. They grab control of almost all of the memory, as well as the critical device drivers, and we even re-wrote the scheduler to make sure the UNIX parts don’t get in the way. We’re still not using the normal UNIX data paths.
Why the difference? One reason is that CPUs are way more powerful now than when we started, so a little bit of extra overhead matters less. (Our first product used a 50 megahertz 486.) In addition, UNIXs have gotten much better. When we started, there was no Linux, no FreeBSD, and AT&T and UC Berkeley were still in a legal battle over big chunks of the Berkeley Net/2 Release.
Although these two approaches feel very different to engineers developing the systems, each with its own advantages and disadvantages, there is little if any difference to the end-user.
(note: without permission to dave)
A customer recently asked, “Is Data ONTAP based on UNIX?” Complicated question.
The first version of Data ONTAP borrowed lots of code from Berkeley Net/2 (one of the earliest open-source releases of UNIX), including the TCP/IP stack, system boot code, and device drivers. Since then, we’ve borrowed liberally from other open-source UNIX releases. We wrote the command line interface from scratch, but we designed it to look like UNIX, since our first market was UNIX system administrators. Clearly, ONTAP is related to UNIX.
On the other hand, ONTAP’s architecture is very different from UNIX. There is no user-space, the filesystem is completely different, the RAID and diskubsystems are completely different and most important of all, the interaction between subsystems is very different. The key data paths from network to disk look nothing at all like UNIX.
You can imagine two completely different ways of building an appliance. You could start with UNIX and strip out, disable, or hide the pieces you don’t want. sOr else you could start from scratch, inventing a new architecture optimized for the task at hand, but borrowing liberally from the UNIX code-base as appropriate. We chose the latter.
Interestingly, our advanced ONTAP GX architecture is built on top of a full UNIX release. We took Data ONTAP, including WAFL and RAID, combined it with the new code from our Spinnaker acquisition, and hosted the combined result on FreeBSD in a combination of user processes and kernel modules. For security and simplicity we have disabled and hidden many parts of FreeBSD.
Even for ONTAP GX, this isn’t quite the “start with UNIX and slim it down” approach, because most of the system lives in large kernel modules that kick UNIX out of the way. They grab control of almost all of the memory, as well as the critical device drivers, and we even re-wrote the scheduler to make sure the UNIX parts don’t get in the way. We’re still not using the normal UNIX data paths.
Why the difference? One reason is that CPUs are way more powerful now than when we started, so a little bit of extra overhead matters less. (Our first product used a 50 megahertz 486.) In addition, UNIXs have gotten much better. When we started, there was no Linux, no FreeBSD, and AT&T and UC Berkeley were still in a legal battle over big chunks of the Berkeley Net/2 Release.
Although these two approaches feel very different to engineers developing the systems, each with its own advantages and disadvantages, there is little if any difference to the end-user.
(note: without permission to dave)
Subscribe to:
Posts (Atom)