2003 MONTANA USCF LICENSE UPGRADE CRITERIA
1.1
General Information
Send all upgrade requests to your Administrator or the USA Cycling office.
For Montana, send requests to:
Rob Whitacre
617 South 9th Street – Unit #3
Bozeman, MT 59715
<EMAIL_ADDRESS>You must follow the guidelines printed below. An upgrade request consists of the following:
(a) a letter requesting an upgrade, which includes a resume of your racing experience or a record of the previous 12 month’s placings. Resumes need to include race name, location, your finishing place, field category, number of competitors in field, promoter name and phone number, other pertinent information that may aid me in the upgrade process.
(b) a stamped, self-addressed envelope.
1.2 USCF License
Your current category will be printed on your USCF License. If an upgrade is approved, an upgrade sticker will be returned to you. Upgrades to category 1 require license reissue ($15 fee). Downgrades to category 5 are not allowed.
1.2.1 Requirements
and Notes by Category
5-4: Experience in 10 mass start races.
4-3: Need 20 points in any 12-month period; or experience in 25 qualifying races with a minimum of 10 top-10 finishes. 30 points in 12 months is an automatic upgrade.
3 - 2: Need 25 points in any 12-month period. 60 points in 12 months is an automatic upgrade
2 - 1: Need 30 points in any 12-month period. 60 points in 12 months is an automatic upgrade
1.2.2
Qualifying Road Races for each
Category
Mass start races include road races, criteriums, cyclocross, etc. The definition for qualifying races is stated in the upgrade section of the 2003 USCF Rulebook. For Montana races I will determine for each race what an adequate field size is for races to qualify for upgrade points.
For Category 5-4 upgrades, I will accept collegiate
races if the license holder requesting an upgrade has participated in NCCA
Collegiate races. Collegiate races may will
not be used for upgrades higher than Cat 4 status. All other
sanctioned USCF races will be used for Cat 5-4 upgrades.
1.2.2 Qualifying Road Races for each Category, cont.
For Category 4-3 upgrades, I will not approve an upgrade if you have only done Montana races unless you’ve competed in the Ecology Center Classic Stage Race. If not, you will need
out-of-state racing experience with larger field sizes as part of your racing resume.
For Cat 3-2 and Cat 2-1 upgrades, I will not approve an upgrade if you have only done Montana races including the Ecology Center Classic Stage Race. Out-of-state racing experience will need to constitute the bulk of your racing resume.
1.3
Points Awarded for Road Placing
Category
Race Type Points Places
4 - 3 RR or Crit 7-5-4-3-2-1 1st-6th
3 - 2 SR/GC 20-17-15-13-11-10-9-8-7-6-5-4-3-2-1 1st-15th
RR/SR 10-8-6-5-4-3-2-1 1st-8th
RR 10-7-5-3-2-1 1st-6th
Crit 7-5-4-3-2-1 1st-6th
2 - 1 SR/GC 20-17-15-13-11-10-9-8-7-6-5-4-3-2-1 1st-15th
RR/SR 10-8-6-5-4-3-2-1 1st-8th
RR 10-7-5-3-2-1 1st-6th
Crit 7-5-4-3-2-1 1st-6th


Toggle navigation
Home
About
Contact
Contact Us
Service 1
Service 2
Service 3
Service 4
Products 1
Process 1
Process 2
Process 3
Process 4
Process 5
Products 2
Process 1
Process 2
Process 3
Process 4
Process 5
Products 3
Process 1
Process 2
Process 3
Process 4
Process 5
Products 4


The SVGPreserveAspectRatio
interface corresponds to the preserveAspectRatio
attribute, which is available for some of SVG's elements.
An SVGPreserveAspectRatio
object can be designated as read only, which means that attempts to modify the object will result in an exception being thrown.
| Also implement | None |
|---|---|
| Methods | None |
| Properties |
|
| Constants |
|
| Normative document | SVG 1.1 (2nd Edition) |
| Name | Value | Description |
|---|---|---|
SVG_ PRESERVEASPECTRATIO _UNKNOWN
| 0 | The enumeration was set to a value that is not one of predefined types. It is invalid to attempt to define a new value of this type or to attempt to switch an existing value to this type. |
SVG_ PRESERVEASPECTRATIO _NONE
| 1 | Corresponds to value none for attribute preserveAspectRatio . |
SVG_ PRESERVEASPECTRATIO _XMINYMIN
| 2 | Corresponds to value xMinYMin for attribute preserveAspectRatio . |
SVG_ PRESERVEASPECTRATIO _XMIDYMIN
| 3 | Corresponds to value xMidYMin for attribute preserveAspectRatio . |
SVG_ PRESERVEASPECTRATIO _XMAXYMIN
| 4 | Corresponds to value xMaxYMin for attribute preserveAspectRatio . |
SVG_ PRESERVEASPECTRATIO _XMINYMID
| 5 | Corresponds to value xMinYMid for attribute preserveAspectRatio . |
SVG_ PRESERVEASPECTRATIO _XMIDYMID
| 6 | Corresponds to value xMidYMid for attribute preserveAspectRatio . |
SVG_ PRESERVEASPECTRATIO _XMAXYMID
| 7 | Corresponds to value xMaxYMid for attribute preserveAspectRatio . |
SVG_ PRESERVEASPECTRATIO _XMINYMAX
| 8 | Corresponds to value xMinYMax for attribute preserveAspectRatio . |
SVG_ PRESERVEASPECTRATIO _XMIDYMAX
| 9 | Corresponds to value xMidYMax for attribute preserveAspectRatio . |
SVG_ PRESERVEASPECTRATIO _XMAXYMAX
| 10 | Corresponds to value xMaxYMax for attribute preserveAspectRatio . |
SVG_MEETORSLICE_UNKNOWN | 0 | The enumeration was set to a value that is not one of predefined types. It is invalid to attempt to define a new value of this type or to attempt to switch an existing value to this type. |
SVG_MEETORSLICE_MEET | 1 | Corresponds to value meet for attribute preserveAspectRatio . |
SVG_MEETORSLICE_SLICE | 2 | Corresponds to value slice for attribute preserveAspectRatio . |
| Name | Type | Description |
|---|---|---|
align | unsigned short | The type of the alignment value as specified by one of the SVG_PRESERVEASPECTRATIO_* constants defined on this interface. |
meetOrSlice | unsigned short | The type of the meet-or-slice value as specified by one of the SVG_MEETORSLICE_* constants defined on this interface. |
Exceptions on setting: a DOMException
with code NO_MODIFICATION_ALLOWED_ERR
is raised on an attempt to change the value of an attribute on a read only object.
The SVGPreserveAspectRatio
interface do not provide any specific methods.
| Feature | Chrome | Firefox (Gecko) | Internet Explorer | Opera | Safari (WebKit) |
|---|---|---|---|---|---|
| Basic support | ? | ? | ? | ? | ? |
| Feature | Android | Firefox Mobile (Gecko) | IE Mobile | Opera Mobile | Safari Mobile |
|---|---|---|---|---|---|
| Basic support | ? | ? | ? | ? | ? |
© 2013 Mozilla Contributors
Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later.
https://developer.mozilla.org/en-US/docs/Web/API/SVGPreserveAspectRatio


 It's a three-day process, but very little of that time involves work on your part, and it will produce the most flavoursome, tender ribs imaginable.
For the dry cured ribs, stir together all of the dry ingredients and rub them all into the rib of beef. Place the beef into a large plastic container and cover with any remaining cure mix. Put the lid on and place into a fridge overnight or for 24 hours.
For the barbecue glaze, place the chopped dates and pickled onions into a bowl. Bring the stout up to the boil in a saucepan and pour it onto the dates and onions. Cover with cling film and leave to cool at room temperature.
In a separate large bowl, whisk together the remaining BBQ glaze ingredients.
When the date and onion mixture has cooked and the dates have softened, blend the mixture until smooth and pour it into the rest of the BBQ glaze ingredients.
Preheat the oven to 130C/275F/Gas 1.
When the ribs have cured, wash the cure mixture off the short ribs and place them into a large casserole pan with a lid. Pour over the glaze and put a lid on.
Place into the preheated oven and cook very slowly for 5-6 hours, or until the beef is very tender. Make sure the glaze doesn’t evaporate - if it is reducing down too much, add some water.
When the beef is cooked, remove the pan from the oven and leave to cool at room temperature. When cool, place in the fridge to chill overnight. When cold the fat will have set on the top and can easily be removed.
When ready to reheat, place the whole pan, with the lid on, onto a barbecue on a low heat. Let the ribs warm through for about 2-3 hours.
When warm, remove the lid and slowly reduce the glaze with the beef still in the pan, basting the ribs every 10 minutes. When the glaze is reduced and coats the beef, remove the ribs from the pan and serve.


Huawei MatePad Officially Coming on November 25th - Gizchina.com
by PierreRate this post
Huawei’s consumer business CEO, Yu Chengdong, just announced that a new member of the Mate family will be released in Shanghai on November 25th. Some netizens quickly speculated that we will see the new MatePad at the conference – they’re probably correct.
As we can see in the teaser above published by Yu Chengdong, we can indeed clearly read the word “Mate”. Now, while the other letters are blurred out, we can still somewhat see it says “Pad”. Thus confirming a new tablet is entering Huawei’s Mate family.
The current Mate series line covers various product categories. Going from mobile phones to foldable devices and laptops such as the MateBook series. So, on November 25th, the Mate moniker will be adopted by the tablet line as well. Most probably a high-end one at that.
Huawei’s MatePad is very likely going to be the first tablet to feature a full screen design. With that we mean a screen that covers most of the screen with a punch-hole to integrate the camera sensor. The tablet is also expected to pack a dual rear camera setup; once again getting closer to modern smartphone trends.
As we previously mentioned, the Huawei MatePad is going to be a high-end tablet. Thus we could find a flagship-grade mobile CPU such as the home-developed Kirin 990 chip; currently the most powerful Huawei chip on the market.
Finally, the MatePad could be available in a more powerful Pro variant. But at the moment we lack any real info about the latter.


The earliest evidence of this concept is the Irving-Williams Series of stability of metal complexes. This states simply that for a given ligand, stability of the +2 ion is in the order:
Ba2+ < Sr2+ < Ca2+ < Mg2+ < Mn2+ < Fe2+ < Co2+ < Ni2+ < Cu2+ > Zn2+
This is essentially due to decreasing size, and in the case of the Transition Metals, also Ligand Field effects.
It is also noted that certain ligands prefer certain metals, for example Al3+, Ti4+ and Co3+ favour one type of ligand while Ag+4+>, Hg2+ and Pt2_ another. These were then classified as type-a or type-b. Type-a was largely the metal ions of Group 1,2 + lighter Transition Metals in high Oxidation States, + H+. Type-b were the heavier Transition Metals and lower Oxidation State metals. Ligands can also then be classified based on their preference for a or b.
| Tendency for a | Tendency for b |
|---|---|
| N >> P > As > Sb | N << P > As > Sb |
| O >> S > Se > Te | O << S < Se = Te |
| F > Cl > Br > I | F < Cl < Br < I |
These were later classed Hard (a) and Soft (b).
Pearson Principle for predicting stability: Hard Acids prefer to bind to Hard Bases, and Soft Acids prefer to bind to Soft Bases. It should be noted though that this is a simple rule, and not an explanation. Thus any acid/base can be classed as hard or soft based on its preference for hard or soft reactants. For example,
BH+ + CH3Hg+ ⇔ CH3HgB+ + H+
H+ is the hard acid, Hg++> the soft acid. For a Hard Base B, the reaction goes to the left, while for a Soft Base B the reaction goes to the right. However the borderline between hard and soft is relative, and so there is no sharp divide. For example, all alkali metals are "hard", but Cs+ is significantly softer than Li+. Similarly R substituents on the ligands greatly influence the hardness/softness, e.g. for PR3 when R is electron-withdrawing the softness is reduced. Borderline acids are typically 1st row Transition Metals from Iron to Zinc, Pb2+, NO+, while bases are typically Br-, N2, SO32-. There are plenty of others.
It is important to make the distinction between Hardness and Softness and Acid/Base Strength. Hardness/Softness has already been defined as the special stability of hard- hard and soft-soft interactions, but Acid Base Strength must also be defined.
Acid Base Strength measures the inherent acidity/basicity of a given acid or base. Measurement requires non-competing solvent effects and therefore is best done in the gas phase.
The inherent basicity is the base’s proton affinity, and this is the energy released from the reaction: B + H+ → BH+. This can be measured using Born-Haber cycles, and the largest known to date is that for N3-.
The inherent acidity is thus proton loss, that is HF → H+ + F-. The more endothermic this reaction is, the weaker the acid. For Lewis Acids, proton’s must be disregarded and the obvious quantity to use instead is electron affinity (same value). Thus a large electron affinity means a strong acid. The EA of a monopositive cation is equal to the EI of the metal atom. Thus it makes sense that Group 1 & 2 metals are weak Lewis Acids, while the Transition Metals are stronger.
The measurement of acid base strength can be converted to solution chemistry by instead considering the enthalpies, as -∆Hf = EAEB + CACB. E corresponds to the susceptibility of the acid/base to electrostatic forces, while C to the susceptibility to covalency. Thus electrostatic acid & base is stable, while a covalent acid & base also form stable. This allows for the prediction of those complexes not measurable. It also usefully contrasts ionic and covalent tendencies for acids and bases.
This simple estimation was later modified to include a -W term, which was RATB and measures the charge transfer occurring as well (receptance / transferance). This takes into account the variation of H+ acid strength in solution / gas phase. As a gas, H+ accepts a great amount of electron density, while solvated H+ is expended this energy already and so the transfer energy is lowered.
With these definitions considered, we can look now at the distinction between Hard/Soft and Strength. A good example are the bases -OH and F-. They are both hard and form stable complexes with hard acids, but the hydroxyl is 1013 times as basic.
The key concept here is that stronger softer bases can displace weaker harder bases from a hard acid like H+, i.e. strengths of base forces reaction in spite of hard-hard considerations. The trend of the Irving-Williams series shows this well, as it is essentially a measure of increasing acidity of M2+ and superimposed upon this is a hard-soft factor. The hard-hard factor only tends to be favoured for acids/bases closely related in strength, and is just a general trend due to the extra stability it confers.
As such, it is important to consider how this extra stability comes about.
The theoretical basis for the hard-hard interaction is taken primarily from an electrostatic viewpoint. Typical hard acids/bases such as Li+ and F- are all typically classed as ionic compounds, so this is valid. The electrostatic (or Madelung) Energy of an ion pair is inversely proportional to the interatomic distance, so smaller ions have greater attractions. Thus, hard-hard favours small ions such as Li+ and F-.
The electrostatic argument cannot be used for soft-soft interactions as the Madelung Energy would be weak. Thus, it can be extrapolated as a covalent factor, so polarizing power and polarizability of the electrons becomes important. Thus soft transition metal acids with dn electrons where n >= 6 show soft-soft interactions (particularly d10). The polarisation effects here resemble Fajans’ ideas.
Fajans’ Rules - originally came about to consider partial covalent character in ionic compounds. They consider the effect of a small highly charged cation on an anion. A large soft anion means the cation polarises it. The extreme of this is the cation penetrates the anion’s electron cloud to share electrons in a covalent bond. There are 3 rules to estimate the extent of polarisation:
Electronegativity is another property that is considered when looking at the basis of hard/soft acid/base. High electronegativity usually corresponds to hardness. It is important here to remember to consider the ion in question, not the atom. For example, Li has low electronegativity, but Li+ is very high due to a very large second ionisation energy. Transition Metals on the other hand have low electronegativity due to variable oxidation states (although in high oxidation states it will increase in value). They are thus soft when in low oxidation states.
The combination of factors above give rise to the Hard-Soft Acid-Base (HSAB) Theory. Attention was then given to the frontier orbitals (HOMO and LUMO) in order to better develop the understanding of the bonding involved.
Using Koopmans Theorem: Energy of the HOMO corresponds to the Ionisation Energy, and the Energy of the LUMO corresponds to the electronegativity and HSAB, it was realised that a Hard acid or base must have a large HOMO-LUMO gap, while the gap for Soft was smaller.
Presence of low-lying unoccupied Molecular Orbitals capable of mixing with the ground state accounts for the polarisability of soft atoms. The consequence of polarisability was distortion of the electron cloud occurring to reduce repulsions and enhanced σ-donation and π-backbonding. Thus soft acid/bases better at π-bonding. Note that longer σ/π bonds are not as strong, hence Se, As, Te, Sb are not as soft as S, P. This is because they need overlap. This is also why CO is so good, being small.
NO contains unpaired electron, and bonding to metal involves:
Other M-N bonded ligands show electronic behaviour.
If NO bends then metal can accommodate additional 2 electron donor ligand. The 18 Electron Rule can be used to rationalise the geometry for coordinated NO and related ligands.
The most common geometry for transition metal complexes.
Complexes of the type ML4L2 exist as cis or trans isomers. Trans [CoCl2(en)2]+ shown:
Trans green, cis violet. [Co(NH3)3(NO2)3] - fac and mer isomers, fac shown:
[Co(en)3]3+ looking down threefold axis - enantiomeric (left).
Note that the molecule Mabcdef (i.e. 6 different ligands around M) has 30 stereoisomers and 15 enantiomeric pairs!
Enantiomers are also found for Mabc2d2, Mabcd3 and Mabcde2.
Separation of optical isomers by chromatography using chiral column.
For cations separate using optically active tartrate anion, fractional crystallisation.
Anions resolved using brucine or other optically active cations.
Absolute configurations by X-ray crystallography.
Ambidentate Ligands - two isomers possible for nitrite when coordinated:
Three different forms for CoCl3.6H2O.
| [Cr(H2O)6]Cl3 | violet |
| [CrCl(H2O)6]Cl2.H2O | blue-green |
| [CrCl2(H2O)6]Cl.2H2O | green |
Different anionic ligands bound.
| [Co(NH3)5SO4]NO3 |
| [CO(NH3)5NO3]SO4 |
Ligand to metal ratio remains constant, but metal-ligand combinations change. Three compounds with empirical formula PtCl2(NH3)2 -
| [PtCl2(NH3)2] | |
| [PtCl(NH3)3][PtCl3(NH3)] | |
| [Pt(NH3)4][PtCl4] | Magnus green salt |
Some 6 coordinate complexes, especially with dithiolene S ligands, have alternative trigonal prismatic geometry.
S-S interactions play a role in stabilisation, but d-electron population also important.
Dithiolenes are examples of “suspect” ligands - can be viewed as neutral or 2-ligands.
WMe6 is another example.
Tetrahedral geometry most common for 4 coordination. Can be distorted for same reasons as octahedral.
Square planar geometry is favoured by many d8 complexes, e.g. Rh(I), Pt(II), Au(III).
Can have optical and geometric isomers.
Diamine complex on the right is enantiomeric:
Factors affecting shape:
Trigonal Bipyramidal and Square Based Pyramidal. The energy difference between the two forms is often small.
The latter often has multiply bonded ligand in the axial site, with high trans effect.
Capped trigonal prism (e.g. [NbF7]2-, or pentagonal bipyramidal (e.g. [UO2(H2O)5]2+). The latter is most common.
e.g. [Zr(oxalate)4]4-. Square antiprismatic structure. Favoured by bidentate ligands with small bite angles and small charged ligands with larger early TMs.
Found for [ReH9]2-
Tricapped trigonal prism.
Also for lanthanides with bidentate ligands with small bite angles.
Many compounds that appear to have low coordination such as CoCl2 are in fact polymeric with halide bridges (or the structure can be viewed using a close packing model).
Two Coordination is common for d10:
Three Coordination is often of the trigonal planar geometry. Groups 11 and 12 again favour low coordination, and 3 coordinate complexes are known for Cu and Au, e.g. [Au(PPh3)3]+.
Also, steric crowding can lead to this coordination number, e.g. in complexes of the type [M{N(SiMe3)2}3].
[M(H2O)4]n+ + 4L ⇔ [ML4]n+ + 4H2O
Overall stability constant,
βn = [MLn]/[M][Ln]
Stability Constant implies the strength of species as ligands relative to the strength of H2O.
K1 > K2 > K3 > … > Kn
This can be explained statistically, as:
ML6 + L’ ⇔ ML’L5 + L
ML4L’2 + L’ ⇔ ML3L’3 OR ML4L’2
Depending on which is displaced, i.e. fewer ligands available for displacement with each step.
Also, thermodynamically, entropy causes the decrease as free ligands are immobilised.
Steric factors - L’ may be bigger than L.
Any deviation from that trend is usually the result of a major change in the electronic structure of the complex, e.g. change of geometry.
Copper(II) - Ammonia. Consequences on K5 and K6 of the Jahn-Teller effect - unusually weak bonding at the 5th and 6th coordination positions. Hence, Cu(NH3)62+ can only be obtained in liquid ammonia
Cadmium(II) Iodide. Stereochemical change from CdI2(OH2)4 (octahedral) to CdI3(OH2)- (tetrahedral). This causes release of additional water molecules.
Similarly, stepwise stability constants for Cd2+ with Br- would be expected to decrease from K1 to K2 to K3 to K4. However, there is an increase from K3 to K4. This is because of adoption of the tetrahedral [CdBr4]2- as water ligands are ejected from [CdBr3(OH2)3]- (entropy driven).
Iron(II)-1,10-phenanthroline. Magnetism change: [Fe(phen)2]2+ is high spin, while [Fe(phen)3]2+ is low spin.
Similarly, for Fe2+ and bipy, moving from K2 to K3 sees a large increase as [Fe(bipy)2(OH2)2]2+ forms [Fe(bipy)3]2+. The key change here is not structural, but a change from t2g4eg2 (high spin) to t2g6 (low spin), and a gain in CFSE. Presumably the 3 bipy ligands is sufficient to stabilise the low spin form, but 2 is not.
| Metal | V2+ | Cr2+ | Mn2+ | Fe2+ | Co2+ | Ni2+ | Cu2+ | Zn2+ |
| Config | d3 | d4 | d5 | d6 | d7 | d8 | d9 | d10 |
| CFSE | 12Dq | 6Dq | 0 | 4Dq | 8Dq | 12Dq | 6Dq | 0 |
| Log K1 (en) | 4.6 | 5.2 | 2.7 | 4.3 | 5.9 | 7.6 | 10.7 | 5.9 |
| Log K1 (edta) | 12.7 | 12.8 | 12.3 | 14.2 | 16.1 | 18.5 | 18.8 | 16.5 |
Also see a similar trend in -∆H, i.e. the trend is insensitive to the nature of the ligand. Peaks at Cu2+ are due to Jahn-Teller distortions (destabilising). Ligands in the plane are stabilised, while axial often do not bind at all.
Across the period, Zeff increases, radii decrease, Lewis Acidity increases, and stability as a result increases. This all implies a stronger M-L bond.
This is known as the Irving-Williams Series - the dependence of stability constants and formation enthalpies on d electron configuration for high-spin complexes of first row transition metal 2+ cations.
Smaller r = bigger Kf.
Also, Electronic Factors - ligand binding governed by charge and MOs:
| σ-donor - favoured | π-acceptor - favoured | π-donor - unfavoured |
High spin / low spin important for d6. Low spin stabilises by 12Dq.
Enhanced stability of chelate rings as compared to a similar monodentate system. Both entropic and enthalpic contributions:
Entropy driven as more free molecules in solution as each ligand displaces 2.
Localised concentrations can also favour:
The other N is now nearby to M despite many solvent molecules - intramolecular faster. Relatively, it is highly concentrated.
Hence, we can expect ring size to matter. As the ring increases in size, log K decreases, as once one ligand point is bound, the second is less likely to attach when the chain is longer (further away). They are however notable exceptions seen with 5 and 6 membered chelate rings.
Enthalpy is also favourable because generally polar groups are brought together - part of mutual dipolar repulsions are overcome in forming a ligand.
The chelate effect is also magnified when there are multiple chelating rings, e.g. in EDTA4-.
When relating these to different metals, we must consider the concept of “bite size” of the chelating ligand. In general, this is larger for 5 membered rings than 6, so then 6- membered favours larger metal ions. Also, the bond angle for 5 membered rings (N-M- N) is smaller, so a small metal ion can get closer to the smaller ring.
Macrocyclic ligand complexes are more stable than open chain analogues. Depending on the system, can have favourable ∆S and/or ∆H, although enthalpy generally dominates.
Major contributing factors to favourable ∆H are:
Overcomes repulsive forces between polar donor groups.
Favourable ∆S results from macrocycles which are less conformationally flexible, i.e. lose fewer degrees of freedom on complexation.
e.g. Crown ethers are more preorganised than acyclic ethers, Cryptands are more preorganised than crown ethers.
Generally,
Spherands > cryptands > crown ethers > polands
↓ thermodynamic stability →
↓ degree of preorganisation →
Spherands = ligands that are completely preorganised for complexation during synthesis.
One in which coordination of L to at least one metal ion is necessary, either for the reaction to proceed, or to change product distribution in favour of specific compound, e.g. pthalocyanines.
R2C=N-R’ formation.
A carbonyl is attacked by an amine, which then loses water.
Metal is coordinated to N.
Control of the reaction is by the size of the template metal-ion used. Small metal cations lead to [1+1] condensations (e.g. Mn2+, Fe2+). Large metals such as Ba2+ give [2+2] macrocyclic products.
Complexation to a metal ion stabilises one component of an equilibrium mixture, shifting the equilibrium to favour formation of the metal complex:
Coordination of the reactive groups to a metal ion which holds these groups (template) in the proper geometry to favour a particular macrocycle. Ring closing reaction:
Orientation by metal template favours cyclic product formation.
Freeing ligand is hard. Either:
Template reactions leading to macrocyclic ligands - Encapsulation Reactions.
High dilution conditions. Simultaneous drop-wise addition of reactants A + B to a vigorously stirred large volume solvent over hours/days. Always a low concentration of reactants → cyclisation rather than polymerisation.


View, convert, save source in xml or json format, or edit and export source to Shortcuts
Author: @gluebyte
Development Tools
This is a developer tool with which you can:
- Select a shortcut or open a source file (from .txt, .json, .xml, .plist or .shortcut) to:
- Quick Look in xml or json format,
- Convert from/to xml and json,
- Save or share in xml or json,
- Optionally edit source then export back to Shortcuts.
- Convert and save source in Tinycut-style text format.
- Useful for overview of structure and variable flow.
- In addition to actions, it shows you (if conditions), “menu titles” and where variables (including named magic variables) are created (→) and consumed (←).
Enjoy. :)


This is application for detecting objects in real-time using any sort of camera. Usage of camera in done through openCV. Basically openCV gets a single frame from the camera and pass it to pre-trained tensorflow model. The tensorflow return the frame with objects identified in it.
posts
Application designed to sending data to user via MQTT. Arduino acts as the sensor connected via WiFi and communicate with broker, which is installed in Raspberry. MQTT Client app is required in ur phone to monitor the data you will receive.
This application transmits temperature and humidity from arduino to AWS IoT through wireless connection(WiFi). AWS IoT then store the record into DynamoDB.
This is chrome web extension that is designed to analyze any object that will be triggered by double click. The data triggered from that will be sent to a google sheet that has to be configured before make this extension working as the google doesn’t allow to create files through script due to security reason.
Responsive & Interactive Web Application for visualizing Hypergraphs.
Provided models have been trained on 10.000 images 64x64, the dataset is custom made and based on CelebA with a little modification. In our project we had to find the best performing model by only looking at papers and testing it with 2 set of faces: cropped (as close to no-background as possible) and large (as much background as possible)
- Top row is the input images, the original ones that the NN has never seen before
- Second row is the noisy images, the input of our NNs
- Third row is the output images for the WIN5_LARGE model
- Fourth row is the out images for the WIN5 model


I had a bunch of issues getting pow up and running after I upgraded to Mavricks. I ended up not installing via the curl method that the 37signals suggests as it wasn’t recognizing my rbenv and was running on my system ruby. So I uninstalled and tried it with homebrew, which required a different path in my .powconfig file. Just like the troubleshooter said it would via the github issue, this worked.
Final code: export PATH="/usr/local/opt/rbenv/shims:/usr/local/opt/rbenv/bin:$PATH"
Boom! Smack! Pow!
UPDATE (Summer ‘14):
The new hotness is ngrok. An easier way to expose a local web server to the internet. It’s the jam.
Works with ngrok localhost:3000 for a rails app for example.
Then open it up on the provided url and you’ve got yourself a stew.
Let’s create our first feature. The anatomy of a feature is the following:
1234
Feature: [feature]
In order to [business value]
As a [role]
I want to [some action]
Notice how a feature includes who, what and most importantly: why.
For example:
1234
Feature: Manage Articles
In order to make a blog
As an author
I want to create and manage articles
Scenarios
There will be many scenarios accompanying a feature. Scenarios will follow the four stages of testing: setup, exercise, verify and teardown. A simple scenario looks like this:
123
Given [context]
When I do [action]
Then I should see [outcome]
The Given step is where you set up the context of your scenario. Every scenario starts with a blank slate, so it is important to create a state in your application for example by creating data in the database, or by navigating to a specific page.
The When step is where you exercise the application in order to accomplish what needs testing. This is usually where you might fill in forms, press buttons, click links, or otherwise interact with the system in some way.
The Then step is where you verify the result, and it’s where we check that the correct pages are rendered, that we see a success or error message, or anything that could help us verify that the prior action was successful.
The teardown, is taken care of by cucumber automatically.
For example:
12345
Scenario: Articles List
Given I have articles titled Pizza, Breadsticks
When I go to the list of articles
Then I should see "Pizza"
And I should see "Breadsticks"
123456789
Scenario: User signs up with valid data
When I go to the sign up page
And I fill in "Email" with<EMAIL_ADDRESS>And I fill in "Username" with "user"
And I fill in "Password" with "password"
And I fill in "Confirm password" with "password"
And I press "Sign up"
Then I should see "instructions for confirming"
And a confirmation message should be sent to<EMAIL_ADDRESS>We can also test a user attempting to sign up without filling in all the fields:
1234567
Scenario: User tries to sign up without a twiddr name
When I go to the sign up page
And I fill in "Email" with<EMAIL_ADDRESS>And I fill in "Password" with "password"
And I fill in "Confirm password" with "password"
And I press "Sign up"
Then the "Username" field should have the "can't be blank" error
Tags
cucumber --tags @billing --tags @important -> Runs the first scenario (Scenarios with @important AND @billing)
cucumber --tags @billing,@important -> Runs both scenarios (Scenarios with @important OR @billing)
so rbenv now does support a ruby version file but doesn’t support fuzzy matching. See.
Multipart = true
HTML forms provide two methods of encoding. The default is application/x-www-form-urlencoded, which is more or less the same as a query string on the end of the URL. The other, multipart/form-data, is a more complicated encoding but one which allows entire files to be included in the data. via
Devise
had trouble with validation requirements built into the validatable module and configuring it to allow a user to edit their profile without requiring a password, which involved destroying the session because the salted password had changed. I ended up ripping it out and going with a validates_presence_of :password, :on => :create instead.
From the docs it’s possible to set up associations within factories. If the factory name is the same as the association name, the factory name can be left out.
1234
factory:postdo# ...authorend
To not save the associated object, specify strategy: :build in the factory:
had a feature that pulls events once they have passed. Heroku’s time zone is by default set to UTC. So I did two things:
heroku config:add TZ=”America/New_York” as described here.
Set config.time_zone = 'Eastern Time (US & Canada)' in application.rb as described in the rails docs.
Fragment Caching
Had an issue expiring the fragment cache. The issue was that when you cache the fragment in your view, a cache digest is being added to the cache key (views/all_available_releases/41cb0a928326986f35f41c52bb3d8352), but expire_fragment is not using the digest (views/all_available_releases).
By adding skip_digest: true to the cache call in the view it should prevent the digest from being used.
Cache digests are only intended to be used with automatic cache expiration. If you need to manually expire cache keys then you can’t use cache digests.
It has been a little more than a year from when I started at Carrot Creative. It has been an exciting year in Carrot history and year in which I had some personal milestones. Carrot was the perfect place for me over the past year and I’m eternally grateful for the opportunity to work on some large scale using a variety of technologies.
I am excited to be returning to the Flatiron School, this time as an instructor. Working with eager students who want to change the world through code is an exciting proposition and one I ultimately couldn’t resist.
so apparently markdown doesn’t come standard? I installed marked as the markdown interpreter.
with an install with npm this gave immediate markdown functionality to the jade templates, but it was still required in the specific model in order to call markdown related functions on a string of markdown within the template helper.
I also need to translate the modifications made to the HTML on the page to be translated back into markdown to store them on the server. This required another plugin and I settled on html.md. The install was clean and worked smoothly from the start.
This in the view
something that was not immediately apparent was the fact that this has different meanings in the template helper versus onRender for example.
Express is a framework that takes Node from a barebones application and turns it into something that behaves more like the web servers we’re all used to working with.
It was advised that bower is the front end dependencies package manager, where the npm is for the backend. see
You specify what dir your want to install the bower packages with a .bowerrc file which goes in the project root. Here are some examples of these types of files.
This tutorial was helpful to get up and running with require.js and bower
The AMD format comes from wanting a module format that was better than today’s “write a bunch of script tags with implicit dependencies that you have to manually order” and something that was easy to use directly in the browser. further reading
The standard loader is RequireJS, but in production you could use a replacement AMD loader called Almond. It is a smaller “shim” loader, providing the minimal AMD API footprint that includes loader plugin support. Some developers like to use the AMD API to code modular JavaScript, but after doing an optimized build, they do not want to include a full AMD loader like RequireJS, since they do not need all that functionality. Some use cases, like mobile, are very sensitive to file sizes. By including almond in the built file, there is no need for RequireJS. almond is around 1 kilobyte when minified with Closure Compiler and gzipped.


--- layout: data_model title: IncidentCategoryVocab-1.0 this_version: 1.0.1 ---
The IncidentCategoryVocab is the default STIX vocabulary for expressing the possible categories of an incident.
| Item | Description |
|---|---|
| Exercise/Network Defense Testing | This category is used during state, federal, national, international exercises and approved activity testing of internal/external network defenses or responses. |
| Unauthorized Access | In this category an individual gains logical or physical access without permission to a federal agency network, system, application, data, or other resource. |
| Denial of Service | An attack that successfully prevents or impairs the normal authorized functionality of networks, systems or applications by exhausting resources. This activity includes being the victim or participating in the DoS. |
| Malicious Code | Installation of malicious software (e.g., virus, worm, Trojan horse, or other code-based malicious entity) that infects an operating system or application. Agencies are NOT required to report malicious logic that has been successfully quarantined by antivirus (AV) software. |
| Improper Usage | A person violates acceptable computing use policies. |
| Scans/Probes/Attempted Access | This category includes any activity that seeks to access or identify a federal agency computer, open ports, protocols, service, or any combination for later exploit. This activity does not directly result in a compromise or denial of service. |
| Investigation | Unconfirmed incidents that are potentially malicious or anomalous activity deemed by the reporting entity to warrant further review. |
| Field Name | Type | Description |
|---|---|---|
| @vocab_nameoptional | string |
The vocab_name field specifies the name of the controlled vocabulary. |
| @vocab_referenceoptional | anyURI |
The vocab_reference field specifies the URI to the location of where the controlled vocabulary is defined, e.g., in an externally located XML schema file. |


<EMAIL_ADDRESS>www.neutronest.moe
github id: neutronest
---------------------
2015.03-Now Research on NLP (National Lab. of Intelligent Technology & Systems, Tsinghua University)
Research Intern
2013-2014 Software Developer (Xiaomi Company)
Working in Miliao team (MiCloud), as a backend developer.
2012.08-2012.09 Software Developer (GeekPark)
PHP intern (one month)
2015-08 Machine Learning Summer School 2015 Kyoto (MLSS2015)
Participant as undergraduate (two weeks)
2014-06 International Conference on Machine Learning (ICML2014)
Participant in ICML2014 (five days)
Micoblog Analysis (Tsinghua)
Antispam (Xiaomi)
feature engineering: generate features that identified spam users effectively. performance: 90%~95% accurate.
user confidence coefficient analysis:
Miliao Muc (Xiaomi)
Tianjin University
Management Information System 2009-2013
Python, Java; Linux, Git,
Haskell, OCaml just a little.
Machine Learning:
DeepLearning: sequence models: RNN, LSTM, GRU and other variants.
computer vision: CNN, cascade CNN, CNN with multi-masks and other variants.
corresponding applications: sentiment analysis, image classification, etc.
Large Scale ML: GraphLab, Spark etc.
Other Machine Learning topics: high dimensional learning, representation learning, AI&Law, etc.
Functional Programming:
Programming languages: Haskell, Ocaml with theories related: Lazy Evaluation, Monad,
pure functional data sturcture...
Basic theories: lambda calculus, type theory, category theory ...


| OSTG | ThinkGeek - Slashdot - ITMJ - Linux.com - NewsForge - SourceForge - Surveys - Jobs - PriceGrabber |
|
|
| Tue, Dec 26th | home | browse | articles | contact | chat | submit | faq | newsletter | about | stats | scoop | 15:57 PDT |
|
login
«
register « recover password « |
| [Article] | add comment | [Article] |
|
Linux Security: It's Not Just About Security
Jon Lasser began the Bastille Linux Project in order to harden the security of Red Hat Linux, the distribution he uses at work. In the process, he began looking at the other distributions to see how they handle security updates, and he was not at all happy with what he found. In today's editorial, he shares his concerns and explains why it matters to you even if you do all your security monitoring for yourself.
Copyright notice: All reader-contributed material on freshmeat.net is the property and responsibility of its author; for reprint rights, please contact the author directly.
As a professional Unix systems administrator, I'm concerned about system security. Keeping unauthorized users off my systems is simply part of my job; doing this requires vigilance in the form of monitoring performance, reading logs, and keeping patches up-to-date. For me, security is about security; it's about keeping my users' projects safe and keeping them comfortable despite a full-time connection to the Internet. As Lead Coordinator of the Bastille Linux Project , a hardening script for Red Hat Linux, I thought my job was to make Linux more secure so beginning users could easily keep their boxes secure. Often, new Linux users have no experience as system administrators or often even any experience with Unix. I thought the best way to tackle the problem was to make it easy to do the right thing. Recently, I've been asked lots of questions about Linux system security by reporters. Often, I'm put on the defensive right away: Does Linux have a security problem? Why is Linux less secure than other operating systems? Is open-source software inherently less secure than commercial systems? I usually begin by explaining that more holes are reported in open-source software before they're exploited, and that the number of actually-exploited holes is no greater -- perhaps even less -- than commercial software. I explain that one reason there are so many break-ins into Linux systems is that there are so many Linux systems on the Internet, and I explain that Linux can be as secure as any other operating system. But Linux does have a security problem. It's not a universal problem, but look at the following list of security Web sites, mailing lists, and update tools for some common Linux distributions:
These are all mainstream Linux distributions, tending towards a general audience; at the least, they're not aiming at the router market or the embedded devices market. These are all products intended to be used by normal people and thrown up on a corporate network or even the Internet. Some may be aimed at relatively expert users, but I'm a fairly advanced user myself, and I still expect that my software distributor is watching out for security at least minimally. That's one of the reasons I don't roll my own distribution. Of the eight common distributions I could think of, three have nothing whatsoever to do with security, and at least one of the others didn't seem to be doing anything useful. No wonder Linux has a security problem: while those four distributions have probably less than a quarter of the Linux market, they tend to be high-profile distributions which garner more than their share of media coverage. These distributions aren't just putting their users at risk; they're damaging Linux's credibility and its image in the marketplace. Every time I'm asked by a reporter why Linux is so insecure, I have to consider Caldera, Corel, Turbo Linux, and Slackware before I can answer. These distributions' total lack of concern with security is an embarrassment to the entire Linux and Open-Source communities. Because of these distributions, I'm forced to admit to reporters that many Linux installations are insecure, and there's little the average user can do about it without dedicating an inordinate amount of time to security work. Most users aren't paid to worry about security, as I am. For many, computing may be only a small part of their work. These people can't rightly be asked to read Bugtraq; they've got work to do. If only systems were kept up to patch, huge numbers of systems wouldn't be cracked. On the university campus where I work, systems have been exploited using the automount daemon bug which is more than a year old, and which has been patched nearly that long. Being a professional, I know that they shouldn't even be running it, because I know that they're not using it. But I can't expect them to know, and I can't even fix it myself: I didn't know that some of these machines existed until I found out that they'd been hacked. Asking these users to read a single, low-volume, vendor-specific mailing list is a pretty good solution -- when those lists exist. Experienced users should abandon Linux distributions which don't provide security fixes in a timely manner and post that information to a Web site, a mailing list, or both. They should abandon these distributions not because they necessarily need the security notices for themselves, but because these distributions are ruining Linux's image not only with novice users, but with the reporters and editors who shape managers' opinions on whether Linux is a viable solution.   The rest of us do lose. It hurts our professional reputations when we stand behind a piece of software with frequent and highly-publicized security lapses. It wastes our time, tracking down hacked user machines for which we're not responsible and rebuilding them from the ground up. It wastes our money, when businesses and government agencies buy more expensive hardware and software for the illusion of security. Solving this problem isn't difficult or time consuming; simply pick distributions which express a basic level of concern for security issues, and let vendors know -- at trade shows, in e-mail, in letters to the editor of your favorite publication -- that security isn't just about security. It's about preserving our reputation for quality, and it's about saving time and money.
Jon Lasser is a Unix Systems Administrator, Lead Coordinator for the Bastille Linux Project , and author of a forthcoming Unix book from Macmillan tentatively titled Think Unix . He's never bothered to take a computer course, except a single Pascal class in high school. He lives in Baltimore with his wife Kathleen, and their three cats: Mallet, Dashigara, and Spike. If for some reason you want to know more, check out his home page .
T-Shirts and Fame!We're eager to find people interested in writing editorials on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an editorial gets a freshmeat t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let<EMAIL_ADDRESS>know what you'd like to write about.
[
»
]
RE: RE: Linux and the Common Man(tm), revisited
Andy Wrote:
RichD wrote: My premise isn't even that every UNIX user should be responsible for understanding UNIX security. My mistake. I must have misinterpretted the part where you screamed Go back and read the sentence after that one ...
if you don't know what inetd.conf is for, if you don't know where your startup scripts are [snip] ... then *you* *should* *NOT* *be* *using* *UNIX*!!!!! Well, you shouldn't.
there's no excuse for that level of incompetence in someone who's educated enough to be a CEO.Everyone who is interested should teach themselves about how computers and networks work, how to configure them, etc. But the reality is that in the long run, to use your car analogy, the people who configure computers are more like car mechanics, not car drivers. CEOs will not ever learn much, if anything, about how computers work. For them it's a tool, not a hobby. It's much more cost effective to have an expert configure their computer than it is for them to do it themselves. Ok, then, let me take the car analogy one step further that that ... Windows Vehicle:
The driver of the Geo doesn't need to know how the engine works, or how to repair it, in order to get from point A to poing B. That's what the mechanic is for. If there's a problem, an "engine problem" indicator lights up on the dashboard. Likewise, the driver of the F-22 doesn't need to know how the radar, avionics, and engine work, or how to repair them, in order to shoot down the other guy. That's what the ground crew is for. The persond driving F-22, however, must have a great deal more knowledge of and competence in the physics involved in maneuvering the vehicle than the driver of the Geo. The "driver" of the Windows box doesn't need to know how files are stored on disk, or how an interrupt vector tells the CPU that the sound card wants some attention. He does need to know enough to use the Start->Shut Down menu item, instead of just turning off the power. He should know enough not to run any .exe files or open any word files that haven't been virus scanned. The "driver" of the Linux box doesn't need to know what an inode is, or how System V IPC works. He does need to know how to log on and off properly, and how to read basic error messages that show up on the console, how to use the shutdown command. He should know the basics of configuring and compiling a kernel, and locking down inetd.conf and the rc.* files. In a corporate environment, most of the more complicated stuff for either system is handled by the IT staff. They take care of things like firewalls at the edge of the corporate network, and shutting off telnet, ftp, rpc, and other such things on machines that don't need them up. At home, it's a different story. Someone using a computer at home is most likely either dialing a modem in to an ISP, or connecting full time with an ISDN or DSL link. (Unless they're a total geek, and have set up their own <IP_ADDRESS> network behind a dedicated NAT-ing/Firewalling box ...) Sadly, most people don't realize the risk they're putting themselves at by doing this without installing and configuring security tools. Even a simple thing like NukeNabber for Windows can help avert a system compromise, if the user is aware enough to yank the phone line out of the wall when a port scan is detected by it.  Anyone running a computer that's attatched to the 'net needs to take the time to learn how to secure it. (By "running" I mean being the person responsible for it's maintenance, as in an IT person for a corporation, or the owner/user of a home machine.) That's just the way it is.  There's no such thing.  Who's better qualified to cook up a machine config that's suited to the local network environment that the local network admin?
Umm ... let's see ... rpm for RedHat, I've used that one. Last time I checked, it did not add or remove links from the rc.* directories, nor did it do a recursive dependancy check to install all the packages that the package I want depends on. No, but it will tell you if you need to install another package that this one depends on. That way, it doesn't install stuff it's not telling you about ... Yet installation programs magically can do this. They seem different to me. If you want Windows' InstallShield Wizard, you know where to find it.
[
»
]
RE: Linux for the Common Man(tm), revisited
RichD wrote: My premise isn't even that every UNIX user should be responsible for understanding UNIX security. My mistake. I must have misinterpretted the part where you screamed if you don't know what inetd.conf is for, if you don't know where your startup scripts are [snip] ... then *you* *should* *NOT* *be* *using* *UNIX*!!!!! moving on... there's no excuse for that level of incompetence in someone who's educated enough to be a CEO. Everyone who is interested should teach themselves about how computers and networks work, how to configure them, etc. But the reality is that in the long run, to use your car analogy, the people who configure computers are more like car mechanics, not car drivers. CEOs will not ever learn much, if anything, about how computers work. For them it's a tool, not a hobby. It's much more cost effective to have an expert configure their computer than it is for them to do it themselves. That's just the way it is.   But I do agree that it would be nice if people understood computers better. Umm ... let's see ... rpm for RedHat, I've used that one. Last time I checked, it did not add or remove links from the rc.* directories, nor did it do a recursive dependancy check to install all the packages that the package I want depends on. Yet installation programs magically can do this. They seem different to me. what are you complaining about? ... not complaing. Just floating an idea. -a
[
»
]
Linux for the Common Man(tm), revisited.
Andy wrote: First, I'm glad the discussion has risen from the gutter. I think some of these slackeware types need to starting dealing with their anger... Well, some of the statements made in the original article (and many of the responses) were just bound to start a religious flame war. Welcome to the wonderful world of Linux geeks ... I have to disagree with RichD's premise that every UNIX user must be responsible for understanding UNIX security. My premise isn't even that every UNIX user should be responsible for understanding UNIX security. My premise is that every computer user should be responsible for understanding basic computer security. The state of the general public's computer literacy is, IMNERHO, simply pathetic! How many people simply assume it's safe to go into Windows and start up their Dialup Networking and connect to the Internet? How many people assume that because they use an ISP and have a dynamically assigned IP address that they can't get hacked? How many people assume it's ok to open that Word file without virus scanning it because they "know" that only .exe files can contain viruses? How many people assume it's safe to get up from their workstation without locking their screen? From my point of view, that's just like driving off in a car not knowing where the brake pedal is, and assuming you're not going to crash into anything. It's just like turning on a band saw and shoving a piece of wood in the general direction of the blades without wearing safety glasses or knowing where the scram switch is, and assuming you won't get a splinter in your eye or cut your fingers off. A computer is a powerful, complex tool that, if properly applied, can boost productivity in the workplace to a great degree. Like any other tool, however, if it is not used correctly, it has the potential to do a great deal of damage. Linux advocates talk about displacing Windows, but it will never happen until secrataries and CEOs can be productive on Linux, too. The tools are there, it's just a matter of R-ing TFM to learn how to use them. And believe me, they barely understand what their account name is. True.  One person must be able to maintain 10's or 100's of "secure enough" Linux boxes. One person, who has even just a little experience installing and securing Linux boxes, can. It would make a great internship opportunity for a CS student looking at getting into network administration ... You don't have to have a PhD in Computer Science to be able to use a computer safely and effectively, just as you don't need to know the physics and engineering of an internal combustion engine to drive a car safely and effectively -- but, as with a car or a bandsaw or any other piece of equipment, a basic level of knowledge and competence is needed. It is this lack of knowledge of the fundamentals of networks and their hazards that causes so many machines to get cracked. With regards to distro install scripts, one thing I find annoying is that the scripts (the one's I've used, at least) only run at install time. I think a better way to do it would be to have an install script that detected the hardware, installed the kernel and other non-optional packages, then rebooted into console mode. Then, use a general purpose tool (one that you could run again later) to enable and disable services, and install/uninstall software. Umm ... let's see ... rpm for RedHat, pkgtool for Slackware, Debian has a package manager, FreeBSD has pkg_add pkg_delete and the ports system, linuxconf lets you adjust all your system settings from an easy to use and understand GUI (in X) or menu system (on the console) ... what are you complaining about? Most distributions even let you select between a Workstation and a Server installation, and adjust what daemons are available by default accordingly. Perhaps they are a bit permissive with things like telnet, ftp, nfs, and other services, but that's only in accordance with the UNIX tradition, where these services are expected to be available. If you have a problem with that, there's always OpenBSD, which shuts everything except SSH off by default.
[
»
]
Corporate LANs and distro install scripts
First, I'm glad the discussion has risen from the gutter. I think some of
these slackeware types need to starting dealing with their anger...
[
»
]
Security? distro independant.
I find fault not with Slackware, or Red Hat's policy on custom packages
being included. My issue only is with the install programs from the
distros.  This is not entirely practical.
[
»
]
Out of the box secure distro? One word ...
OpenBSD. By default, remote access services are disabled until the admin explicitly goes into inetd.conf and enables them. Slimy is correct in saying that I miss the point of the main article in my previous post. I wasn't aiming for it. I intended the post in context with the other replies talking about how there should be a distro that is "secure" out of the box. (I guess I missed that by a hair, too ;) The simple truth remains that there just is no such thing. The security of any system, no matter what OS it is running, is a function of the cluefulness of the admin. A well run Linux box will be more secure than a poorly run OpenBSD install. A well run NT server will be more secure that a shoddily maintained Solaris 7 box. Of course, the only way to have a system that is completely secure from being hacked on the 'net, is not to have it on the 'net at all. Then all you have to deal with is the security of physical access to the machine itself ... we've all seen the draconian measures that Hollywood producers can think of to try and do that, and Tom Cruise was still able to steal data off of it in Mission Impossible ...
[
»
]
Missing the point
While I agree with RickD's comment (especially the first paragraph), I
believe it misses the main point of the article.
[
»
]
Linux, security, and the Common Man(tm)
Linux is a UNIX style operating system. UNIX was not originally intended
for the "casual" or "home" user ... they just didn't exist in 1969.
[
»
]
ok ok enough bickering
Agreed, the paper did seem like an attack on Slackware do to the complete
misconception about Volkerding's view on security. The sites and lists
have been pointed out enough in the comments. The man has appologized so
lets move on.
[
»
]
Let's get the facts straight
Being the person at Caldera who's responsible for security issues, I felt not just a little insulted by your claim that Caldera is one of the distributions that doesn't to anything about security. You write, in trying to apologize for your unfair treatment of Slackware: ``In the old days [...] Slackware had huge numbers of security holes.'' This sentence enforces my suspicion that your article is based much more on dated stereotypes than real understading of what goes on in the Linux security area. If you go back to some time around 95, I grant you that Linux distributions used to resemble leaky buckets more than a secure OS. This, and the fact that Linux was ignored both by CERT and (to a large degree) by bugtraq as well lead to the establishment of various Linux security resources--such as a the linux-security list. Since then, most Linux distributors, including Caldera, have started to put a lot more emphasis on security. There is even a certain amount of information sharing and coordination concerning security issues among Linux distributors. I have personally audited most if not all setuid applications and a number of network servers shipped with OpenLinux. Linux as a whole has profited from this. And we're not the only Linux vendor trying to address security problems proactively. Working in the security area myself I can on the other hand understand your apparent frustration. Making an operating system more secure is an uphill battle you cannot win. Distributors make mistakes in integrating software with their product (or they make choices you consider a mistake). Programmers insist on putting the same bugs into their programs over and over again (do a grep strcpy over the pine sources one day). Many users expect things to "just work" and don't take security serious until they get hacked. However don't blame distribution maintainers for a problem that has many more facets--especially if your assignment of blame is based on sloppy research. On the overall scale, Linux security has improved a lot over the past few years--and while I agree that there's a long way to go, progress will depend at least as much on creating more secure software in the first place as on the vendors' timely delivery of patches.
[
»
]
we all know why he wrote this
it wasnt to get publicity, or for his own ego. we all know he wrote this article for a free tshirt, i know im gonna write one myself.
[
»
]
Another Slack Flame?
Well...
[
»
]
a secure distribution
Different distributions try to address different issues as seen by
different kinds of users, all with different experiences and different
goals. The very fact we have so many distributions attest to the
diversity of the user base. This is something that Linux distributions
(and their BSD cousins) have over that commercial OS we've heard about.
[
»
]
Oh my.
Jon Lasser brings up some very good points, and his editorial is well-suited to the Linux community. As one of several student Unix sysadmins in the computer science department, I have to deal with the same types of things he does. One of the reasons we've opted not to go with Linux 100% but instead concentrated on IRIX and Solaris is because (1) we feel IRIX has a proven track record of being more stable and secure than Linux; and (2) because Solaris provides a proven environment in which our CS students can code. This does not prevent many attempts to exploit our machines, however. On the average, I spend nearly twenty minutes *per hour* scrounging through logs and checking stats to ensure that my fellow students are safe at what they do best (coding). This does not come at an easy price. Since I'm only one of a few security-minded student sysadmins, I have to make sure that my coworkers are kept current on the latest exploits, security advisories and fixes, etc. [I mean this as no offense to anyone, but I've also noticed that the irc network EFNet seems to split a lot more often now that Linux ircds have popped up. Things weren't this way when they stuck to *BSD daemons. *sigh*] I simply wish we could all just listen to what Jon Lasser was trying to point out instead of nitpicking over the details of whether or not a particular distribution has security lists/pages/whatnot.
[
»
]
re: 5 minutes a month
I have to chime in on the 30 min/day / 5 min/month issue... If 1000 programmers that bill out at $100/hr spend 5 minutes every month checking for updates, in a year that's a loss of $100k...
[
»
]
Re: Linux Religions
Its a _natural_ human reaction to defend your favorite [friend|ice cream
flavor|car|religion|pet goldfish|child|pez dispenser|whatever], especially
against undue and misleading criticism. When you criticize someones
favorite thing youre criticizing them for choosing that thing as their
favorite... pretty elementary principle... why do people have such a hard
time understanding it?
[
»
]
Abandon Slackware 3.0 Instead Use RedHat 4! :P
"But I'm really curious as to why everyone took this as an attack on
Slackware, specifically. It
certainly wasn't intended to be that."
[
»
]
Missing the point...
Unfortunately most people who've responded have missed the whole point.
All major distributions which I'm aware of come out of the box with too
many services enabled, and too many potential holes for new users to cope
with. They could all use a front-end script or dialogue which would ask
new users what actually needs to be enabled, and then disable everything
else by default. I would rather assume that users who need the services
will need to learn enough about the process to be able to enable them
themselves anyway.
[
»
]
Linux Religions
The feedback gained from this editorial demonstrates one facet of the linux community that I find tremendously childish and immature - religious dedication to individual distributions. As much as I am a linux advocate; linux is an operating system, to be used. Some people appear to shift the focus from the operating system to a particular vendor's own cobbling together of software and scream loudly when there's even a hint that somebody is 'attacking' their pet distribution. Grow up, children.
[
»
]
Security.
Jon stats that when he used slackware it was way back when the security wasnt considerd. And that his article was written not in attempt to attack slackware and other distro's but to show the need for security in linux. He might not of ment for the attack on slackware but when a nobody, nerver used linux user read's your article and decides to go with linux from the facts that u offer he will determain to follow redhat when your facts arnt uptodate or even fully looked into. Thats why it attacks slackware because the pertential users belive what they read. And this lowers the possable users for slackware to increase. Also i couldnt write a arctile on Windows systems if i had only run win 3.1 and win 98/2000 was latest venture. I would only be showing my lack of facts on that subject.
[
»
]
Read the message, not the words
I think people are getting a little bit too inflamed over the mistakes
concerning slackware.
[
»
]
Slackware Linux VS other *nix OSes and Secuirty (a mouth full)
As others have I must add my 2 cents, I curently am an administrator for a
Shell providing business, as you know are normaly the first targets of any
hack, exploit, etc. Personaly I have tried many versions of Linux and
*nix systems to find that I personaly prefer Slackware Linux. Not only
have I found Slackware to be more secure, with less exploits, I have found
it even easier to get the updates and install them with-in little time. I
do have to state that Jon did make a large accident by stating that
Slackware did not have any mailing lists etc, especially since he is
doing so without even using Slackware him self, which at least he was
honest about.
[
»
]
Slackware Linux VS other *nix OSes and Secuirty (a mouth full)
As others have I must add my 2 cents, I curently am an administrator for a Shell providing business, as you know are normaly the first targets of any hack, exploit, etc. Personaly I have tried many versions of Linux and *nix systems to find that I personaly prefer Slackware Linux. Not only have I found Slackware to be more secure, with less exploits, I have found it even easier to get the updates and install them with-in little time. I do have to state that Jon did make a large accident by stating that Slackware did not have any mailing lists etc, especially since he is doing so without even using Slackware him self, which at least he was honest about. The Slackware Linux developement team puts a lot of time into making sure the distribution is as secure as posible before releasing it, and personaly I think if Redhat put a little more time into do the same before releasing each dist. it might be a bit more secure it's self. Maybe I am bias to Red Hat because I have seen it hacked so many times and at the same time not very many people can hack Slackware, or maybe it's just my experiance with Slackware that has drawn me to it, I am not sure. One things for certain though, Slackware does have less exploits released for each of there distributions. Finaly, the only thing I have to say is I appriciate these fourms, it gives us a chance to hear opinions from lots of people on security and not just one persons views. I think the only reason that Jon has recieved so much flaming on his editorial is because he didn't take the time to think that before you judge something you should use it your self. Many people are opinionated on which Linux system people should use, as hard as that is to believe, and tend to take things to the extreme when someone makes comment on it. I guess in a sense I am one of those people as well, but as I have used Red Hat, Debian, OpenBSD, SCO, Solaris, and many other *nix oses, I feel that my decision in a *nix OS is an educated decision. Cheers, The Bug<EMAIL_ADDRESS>[
»
]
Linux Security
Hi, just some simple questions.
[
»
]
Editorial Correction
I think that there has been an adequate listing of the incorrect facts in this article. The author should probably go back, re-think the premise, get his facts straight, and re-write and re-submit this editorial. I don't think that something so obviously full of omissions and (yes, even we Linux people do it) FUD should be left posted in such a high-profile location. And Mr. Covey, (or someone from the FM staff) please do a little fact-checking of your own on these?  And as far as bettering the security on the net, im sure most distribs are secure when they're released, it's just after time that people go looking for problems, which is a good thing, but that is also why you should be looking at least once a day, if you want to keep your box secure. And my final comment for the day, when something has a mailing list, such as slackware, it shows the maintainers are looking out for the problems and putting them at one central location for the users to look at, see a problem, then go and get the patch or do whatever needs to be done.
[
»
]
Research
Come on!
[
»
]
Tune in next week for
ok... here goes.
[
»
]
Re: half an hour a day?
Perhaps half an hour a day was a bit too much for the average person. 10minutes would work just as well If it takes more than 5 minutes a month, it's not going to get done. Really, non-hackers just can't be bothered with this kind of stuff. That's why, if you want to improve the overall security of the net and the reputation of Linux as a whole, you need to secure it at the source: the distributions need to be more secure by default, and it needs to be possible for installations to remain secure without the end users having to spend any brainpower on it at all. Because they just won't.
[
»
]
misinformation
You have misinformed people. There is a Slackware security mailing list. Slackware is secure and so is Debian. We're not talking about 'the old days' here; we're talking `today`. I hope you get a lot of flames on the subject, as you flamed a lot of good distributions out there. Even in your sorry message you don't stop flaming and make wrong assumptions about certain distributions, since these cannot be called facts. I don't know/care if you're getting paid to do this but it certainly looks that way. Well, you obviously got a name now, Jon Lasser.
[
»
]
half an hour a day?
Perhaps half an hour a day was a bit too much for the average person. 10minutes would work just as well, quick skim of the headlines on your linux site or reading the security mailing list. These are not hard nor time consuming things to do. And as far as picking out one trivial thing, if he got this wrong when it's blatently obvious and easy to find on the site (the security list), i was wondering what else he had missed or not cared to inform anyone of, in his pursuit of this editorial.
[
»
]
Slackware, security, and so forth
I noticed about 3 people claiming that Slackware is quote "the most secure
distrobution" around. This is in fact not true, and neather is saying
"Redhat is the most secure" or Debian or Caldera, or any distrobution or
Operating system. Even your linux box in the corner of your office with a
static ip, with just telnet and ftp services running, and all the latest
patches you can think of put on it; is ALOT less secure then if you pull
out the ethernet wire. In this day and age there is no "most secured"
linux distrobution. There is always something else you can do to make it
just a little more secure.
[
»
]
Touche..
"But if I can't hold someone to past mistakes, how can I judge current
performance when I'm measuring the invisible (as good security is)? :-)"
[
»
]
Aha!
But if I can't hold someone to past mistakes, how can I judge current performance when I'm measuring the invisible (as good security is)? :-) Exploits come out for Red Hat first because there are more targets on the net. Exploits used to come out for SunOS 4.x for precisely the same reason, but that didn't mean that Ultrix was more secure. (Point of fact, it probably wasn't, it was just less tested.) And the fact that Red Hat releases security fixes fairly promptly means that it's possible to secure the system in a pretty much up-to-date fashion. But that only answers half the question: so now I know why people take Slackware to be the target (because I made a mistake which gave them a foothold from which to attack me), but why do they think it's all about Red Hat? On the basis of the article, it seems clear that SuSE, Debian, and Mandrake are all probably more secure than Red Hat. The fact that I've got a whole project just to secure Red Hat seems as much proof as any that it's not especially secure -- but the fact that they've got some security resources certainly means they're trying. (And I started Bastille not to secure RH for myself, but because there are dozens or hundreds of user-administered Red Hat boxes on the campus of the university where I work. I need a way to secure those machines when I have no direct control over them -- which means I need to secure the OS they're already running.) At any rate, other than the blurb up top (which I didn't write), I don't even mention Red Hat in the article except in the list of Linux distributions and their security resources. I listed it up top because it seems to have the largest number of users, not because it was the best.
[
»
]
A corrected list
While Mr. Lasser makes some important points, the blantant misinformation in his article certainly detracts from its overall impact. He has clearly never used most of the distributions he disparages. From just my personal knowledge and a few minutes of browsing around, here are corrections to several of the gaps and mistakes in Mr. Lasser's list:
[
»
]
Slackware security again
I think people took it as an attack on slack because what was said is
wildly untrue, slack may have been a pile of security holes in the past, i
dont know, as i said ive only been using it since 3.2, but i dont think you
should hold patrick to past mistakes, as slackware now is (IMHO) very
stable and secure. Check out any exploit site and see how many exploits
there are against slackware vs. redhat or any other dists, people may
argue that this doesnt prove much, but it puts me at ease.
[
»
]
I can't understand
What I can't understand is how so many people who have been involved with Unix and Linux for so long still use the term hack to refer to a computer break in. Machine's can get hacked, but that's usually a good thing. People getting hacked? Not too sure about it, but whoever it is might not like it. Hacking software, now that's something that's a real good thing. There are many other kinds of hacks, some of the more famous ones are listed at http://fishwrap.mit.edu/ none of these have to do with computer break in. I agree though, that several distros are not secure to start with, and it takes a lot of reading to secure a new system.
[
»
]
Oops
Yep, I did somehow manage to miss the Slackware security mailing list. I swear I went to the site and looked around before claiming not to find anything, but somehow I still made a mistake. I can't speak to the security or insecurity per se of Slackware 7, as I've not used it, but I'll note that most of the recent security holes in Red Hat and Debian (with the very notable exception of problems with Red Hat's usermode tool -- a very, very serious problem) have been bugs in the underlying code, not particularly related to either of those distributions. If those bugs aren't present in Slackware, that's either because those packages weren't included in Slackware (not a bad thing, just a point of fact) or because Slackware fixed those bugs before anyone else knew about them and failed to backpropogate the fixes. I don't think it's the latter. In the old days (pre 7.0, maybe another level back beyond that or so, I can't remember the last version I used), Slackware had huge numbers of security holes. They just ignored them. And the sources never seemed to be able to produce the binaries which were included -- sometimes it was obvious that the included sources were pre-slackware-patches, as the compiler would spew errors. I certainly hope (and to some degree expect) that this situation's been cleaned up by now, but this made it impossible to audit slackware's security if you wanted to. But I'm really curious as to why everyone took this as an attack on Slackware, specifically. It certainly wasn't intended to be that. I certainly think that Slackware's record on security could stand improvement -- I'm more impressed with a large number of found and fixed bugs than an apparent lack of them in a full-featured Linux distribution -- but as far as I'm concerned in the article, this isn't about any particular distribution. What it is about is why security is important, even if you personally can handle yourself. Claiming otherwise is kind of like claiming that ISO9660 filesystem support in Linux isn't worth keeping in the kernel simply because you personally don't use it: it's a fundamental, enabling feature of the environment for any number of users. It's also about the importance of Linux's image in the media, and simple things we can do to improve that image. If you personally don't care who besides yourself uses Linux, that's fine. But I need Linux to look good in the media, so that I can push for it in appropriate projects at work and elsewhere. Also, a good image for Linux in the media makes it more attractive for companies (ie Creative Labs) to write open-source drivers for hardware which is nice to play with. :-)
[
»
]
Slackware security
Is it just me or does this "professional" not know what hes talking about? Ive been using linux since slack 3.2 and ive found that slack is the most secure distro, with debian coming in second and redhat coming in somewhere near dead last, being the hackers paradise of buffer overflows and 'enabled by default' services that it is. As far as the security/patches/support go, check out slackware.com and see whats at the very top of the page, also slackware.com/lists. While jeff did make some good points and touch on some issues that need to be addressed, he should really take a closer look at the actual OS next time.
[
»
]
All people seem to be able to do...
is dis other distributions versus discuss the problem. Are we so insecure that we have to build a religion around what distro we use and why the others are evil? Its like watching a Baptist convention talking about the evils of Catholics/Lutherans (and as about as worthwhile). Slackware 7.0 is a very big improvement over earlier versions out there. Patrick seems to be much more in tune with putting out things with the 4.0/5.0/6.0 Betas than I have seen him do in years (since the 2.x days). I dont know the reasoning behind it, but once slackware.com came into existance... the quality of the Slackware machines I dealt with seemed to increase also. I dealt with too many people with hacked Slack95 boxes with exploits that had been around way too long. Going to the cdrom.com site usually had out of date info. Now I see a central site and people find things rapidly and cleanly. I used to use slackware up until 1996 when I switched to Red Hat because I was tired of finding exploits and the Slackware response was "Well patch it and compile it for yourself. We will put out a fix next release"... which never came. When I found them in Red Hat, I saw an RPM at a central spot.
Now is Red Hat perfect? NO . There are bugs and it could always tighten things up here or there. However I know every time a change is made to tighten security up... there are howls of "Why did you change this/that." The same is true for SuSE, Caldera, etc.  Anyway back to the main point.. which is what is the problem. The problem is that Linux is not for System Administrators anymore !GASP! . Sorry most of the people who are using Linux probably know only enough system administration to start a modem and stop a modem... and that may be a stretch. And that is what you get for having an open community and saying things like "Stop using Microsoft... use something better... also we are a community versus an elitist club like XYZbsd, etc." (Not saying BSD is elitist, just a very common argument I hear about why Linux is better). Most people use computers as an ends to a means as JWZ said. They use them to browse web sites, answer email, write documents and letters, scan pictures in for a family album. The computer to them is nothing more than a tool.. as much as the car gets them to and from work. With this being the case, and being that we are supposed to be a better OS and a better community... we need to make sure that we have a better attitude towards security. I dont feel boycotts are needed. Tools that help home users (not hobbyists) get working with Linux are what is needed. Anyway my 2 cents of many. Stephen Smoogen
--
[
»
]
Needed to be said.
Defining security without using the word "secure" is a task into itself.
We've all installed a linux distribution, and we've all gone and cleaned
out inetd.conf. All of us. Everyone one of us. Think about it. How
much time and energy is wasted to clean out inetd.conf? To turn off
portmapper? To do all the rest?
[
»
]
Security
I think one of the main concepts that is missed here is that the average, non-expert, trying Linux because they're tired of Microsoft user doesn't want a system that they have to do any real configuration on. They want everything to work, even if they have no need at all for the service they're running. You'll get users demanding that the ftp daemon work, only for you to find out that they're logging in to the machine from the same machine, and have no real need for it to be running at all. Tell them that it's a good idea to disable it, and they'll say that they 'might' need it, and want it there. Current distros do seem to have server written all over them, but that doesn't really seem to be the market they're trying to hit lately. Some companies don't have the resources to re-release their software every week. There are deadlins for pressing the CDs, writing the manuals, testing the software, etc.., etc. It's not always very practical to try to include the latest fix every other day in the released distro. As for security advisories, for Caldera go to http://www.calderasystems.com/support/security/ I love it when people say things don't exist...
[
»
]
Comments
I have to agree with jwz on monitoring for security patches. That should be
the job of the system administrator(s). End users have more important
things to do (as far as the company is concerned) than monitoring patches
for their OS. If the system administrator doesn't know where to look for
security advisories and patches, then maybe it's time to find a new system
administrator. I am not a system administrator. I'm one of those geeks at
the company that brings in money on contracts. I have enough things to do
at work that I don't need the added burden of duplicating the work of my
company's system administrators (no matter how bad they may be).
[
»
]
Linux is Insecure
Okey, First,its not the flavor of Linux that you are ruinning, its the person behind the computer. Computers don't get hacked, people do.  Second, Redhat is bad. Everytime a new version of Redhat comes out is because there are two remote exploits for the previous version. Well, it just depends on the admin, not the flavor of Linux system.
[
»
]
Does he get paid for this
I can not believe someone that has been in the job area for anytime would
make those assumptions about Slackware. It is by far the most secure
flavor out there. And there are lists and sites for Slackware
www.slackware.com and www.linuxmafia.org just to name two. When I do a
comparison of changelogs I see RH has about 10+ security fixes and growing
fast Slackware only has 2. In the 5.2 vs 4.0 we saw about 30vs3 . Redhat is
good mind you but should be saved for the workstation or webserver with no
users type install. As long as they try and change programs from the
original authors intent they will have this problem they taint about 40%
of the apps included if you look at the odd ball versions they give them.
Slackware on the other hand uses programs as is and does virtually no
modifications which always seems to get RH in trouble. They have this
mindset that once they "brand" a program the user thinks its going to be
better I this is almost never the case and alot of this is done by what I
call "KTWFF" Kids That Work For Free. As for the others Mandrake is
nothing more than a modified RH and falls into the same catagory Debian is
pretty good about security but also gets prone to the above but is still
much better. Sorry to flame on so much but the public is so miss-informed
that it just scares me sometimes and the RH jaugernaut scares me also. I
have been in this biz for some years now and when I get hired for consult
and I find they are running RH that is the first thing to go I dont knot
have the time to try and keep up with it. Flame off
[
»
]
Slackware again
I am a bit suprised that such a "serious" guy can wrote this on slackware.
By experience, it's the most secured linux I know. People before me add
comment on the mailing list, and the repository of patch. You can notice
there are few patches, it's because Patrick Volkerding has always take
care of security in his distribution of linux before releasing it. there
are also less packages than other ones but I sleep better.
[
»
]
a couple of points
The bigest problem that I have found with linux distributions is the
[
»
]
Re: no slackware security list?
What you're doing is picking out one trivial error and using it as an excuse to ignore the very good points he made.I don't think so..
[
»
]
Slackware doesn't take half an hour per day to patch
Slackware security mailing list info can be found at www.slackware.com/lists , brought to you by David Cantrell. This has been in place since October at least. You can find all security patches by ftp on ftp://ftp.cdrom.com/pub/linux/slackware-7.0/patches/ (for Slack 7 of course, for Slack 4 you'd find them here ). A Changelog in that directory tells you the when, why and do-i-need-them about these patches. That the author didn't look up the distro's before saying something about them may be a trivial mistake, and I hate to go against jwz for anything, but it does matter for Slackware users and potential Slackware users if Slackware security is declared sloppy.
[
»
]
Re: no slackware security list?
i get at least 1 hack attempt a day. And strangely enough none of them seem to have worked. Why? Because i spend half an hour a day checking new email for problems, and checking websites for problems with anything i'm running. It's great for you that you've got the time to do this. But for the vast majority of people, asking them to spend half an hour a day just looking for security fixes is completely unreasonable. If it takes half an hour a day of every user's time to keep their system secure, then there is something fundamentally wrong. That's a huge amount of time. Try to put yourself in the shoes of someone for whom messing with their computer is a means to an end, rather than an end in itself. They just won't do it. They have more important things to do. Things that pay the bills.
So if this professional sys admin has misinformed you of the slackware side of linux, what else could he be wrong about? I could be interpreting him wrong, or i might just not be thinking clearly tonight, What you're doing is picking out one trivial error and using it as an excuse to ignore the very good points he made.
[
»
]
no slackware security list?
I'm a home and work user of Linux, my flavour of choice is Slackware. I've used most of the major distributions and am forced to use a few at work. As far as Slackware goes, it does have a security mailing list which i am subscribed to, it can easily be found at www.slackware.com which also tells you that all of the current and future versions dir trees will have a patch dir, with patches for that particular version. I also sit on a 24/7 internet connection, with a static ip, i get at least 1 hack attempt a day. And strangely enough none of them seem to have worked. Why? Because i spend half an hour a day checking new email for problems, and checking websites for problems with anything i'm running. So if this professional sys admin has misinformed you of the slackware side of linux, what else could he be wrong about? I could be interpreting him wrong, or i might just not be thinking clearly tonight, but i dont and never have had problems with the slackware distributions.
|


{% extends 'base.html' %} {% set mytitle="dang-bars" %} {# ----------- title -------------- #} {% block title %}{{ mytitle }}{% endblock %} {# ----------- content ------------- #} {% block content %}
This page contains experiments with D3, Angular, and Pelican.
Let's start with a simple Angular.js Hello World:
The following example shows a simple bar chart that is implemented as an
Angular.js directive. This makes it possible to use HTML code like <bar-chart></bar-chart>
and have it translated into Javascript code that assembles the data and
builds the D3 bar chart.
And now a double-chart that re-uses the same directive with an option to sort the data or not.
This double-chart demonstrates how Angular.js directives can be re-used, and further, how options can be added to the directives to make it possible to re-use directive code to construct several different plots.
These charts also share a selection, via a variable managed by the controller that instantiates both charts. This allows the charts to share the selected point without having to interact with each other or create interfaces for each other.
The following bar chart is a multi-series bar chart, demonstrating how to plot multiple x-y relationships on a single bar chart. This multi-series bar chart is drawn using an Angular.js directive.
This example adds a button group that allows the user to sort the data. Each time the data is re-sorted, the bar chart is re-drawn. This is possibLe using the variable watch functionality built into Angular.js.
These examples demonstrate the use of animation for bar chart transitions. The first animation example modifies the sortable bar chart example from above, but animates the sorting of the bars.