spot

Argumentet att "det är lättare att hitta buggar som man kan utnyttja i en programvara med miljoner användare" borde ju inte bara gälla för virus/spyware/crackers m.m. utan även för operativsystemtillverkaren. Om fler buggar upptäcks borde väl fler buggar fixas?

Vikten av att ha ett väl fungerande underhåll av programkoden, strikta rutiner för säkerhetsövervakning tillsammans med en effektiv infrastruktur för att distribuera uppdateringar kan inte överskattas.

Hur väl detta efterlevs i Redmond låter jag vara osagt, men i Cupertino fungerar det faktiskt bättre än hos de flesta andra.

Det låter som om webbservern skickar ut PDF:en med fel mime-typ och därmed vet inte din webbläsare vad den ska göra med filen.

Kontrollera genom att skriva följande kommando i ett Terminalfönster:

curl --head "http://adress.till.pdf.du.vill.hämta"

Då får du information om vad för sorts fil webbservern menar att den skickar ut.

Kontrollera först att första raden är "HTTP/1.1 200 OK". Är den inte det kan det vara nåt annat strul, exempelvis stavfel eller mellanslag i adressen till PDF:en. (Ersätt varje mellanslag med teckensekvensen %20)

Längst ner i svaret finns värdet "Content-Type". Detta ska vara application/pdf (eller möjligtvis x-pdf) annars är webbservern felkonfigurerad. Påpeka i såna fall detta för er sysop.

$1 i ett shell-script substitueras med första argumentet till kommandot.

($0 substitueras med kommandot självt, $2, $3 osv substitueras med andra, tredje osv. argumentet.)

Du använder väl InnoDB och inte nån annan tabellhanterare?

Eftersom jag bara provat med en person hittills får jag nog ta tillbaka mitt "det går finfint". Det verkar istället som om det krävs att personen kör senaste ICQ-lite för att det ska funka.

Prompten kan se ut på det sätt man själv önskar. Detta uppnår man genom att sätta variablerna PS1, PS2, PS3 och PS4.

Som exempel innehåller min .bashrc följande rad:

PS1="[\h:\w] \u$ "

För att hitta rätt flaggor är det bara att läsa man-sidan för bash. För att snabbt hitta rätt kan man söka på "PROMPTING".

(Om det inte är allmänt känt kan man söka i pagern genom att skriva "/sökord" (utan citattecken givetvis, i detta fall /PROMPTING) och trycka enter. För att hitta nästa, skriv / och tryck enter igen. Sökningarna är case-känsliga.)

Kanske inte skäl nog för att inte uppdatera Mac-klienten, men sedan AIM och ICQ kopplade ihop sina nät går det finfint att hålla kontakten med ICQ-folk med iChat. (Jag tycker mig till och med ha hört att nån kopplat upp sig med sitt ICQ-nr i iChat, men det låter jag vara osagt...)

Det enda som påverkar rådatat är slutare, bländare och ISO-inställning (eftersom det sker en analog förstärkning av signalen från sensorn innan A/D-omvandlaren). Övriga värden, som exempelvis vitbalans, ljushet och kontrast, påverkar INTE rådatat, endast den i kameran genererade JPG-filen. Däremot sparas givetvis dessa värden i råfilen, men endast som värden, själva bilddatat är oförändrat. Ett RAW-konverteringsprogram kan sedan (och gör oftast så) välja att ta dessa värden som utgångspunkt.

Photoshops Camera RAW baserar inte sitt histogram på några värden som finns i RAW-filen, förutom själva bilddatat; den gör en lågupplöst förhandsbild (och utgår då oftast från de värden, ex vitbalans, som finns lagrade i RAW-filen) och genererar sedan sitt eget histogram. Justerar man sedan exponeringen görs en ny beräkning.

20D m fl Canon-kameror (jag har tyvärr inte nån Nikon, därför uttalar jag mig inte generellt) baserar sitt histogram på de JPG-bilder som skapas samtidigt som RAW-bilden registreras. Därför kan detta histogram vara missvisande och exempelvis indikera att man överexponerat en del trots att detta lika gärna skulle kunna bero på att man valt alldeles för höga värden på ljushet och kontrast i kameran.

Om det är histogrammet på displayen du menar, så är det i alla fall så hos Canon-kameran att det INTE är histogrammet för RAW-filen som visas utan den samtidigt registrerade (och med kamerans parametrar behandlade) JPG-filen. (En RAW-fil är ju faktiskt ingen färdig bild ännu, bara en skock mätvärden från en CMOS- eller CCD-sensor.) Titta istället på histogrammen i ditt RAW-konverteringsprogram och gör exponeringsjusteringar där.

Samma sak när du tittar på färgtemperaturen; du kan ju själv välja vitbalans i efterhand om du arbetar med RAW-filer. Kameran sparar bara en parameter i RAW-filen som du har all rätt i världen att justera i efterhand. Däremot appliceras ju detta värde på den JPG-fil som kameran skapar. (Därmed inte sagt att man inte kan spara tid genom att vitbalansera manuellt vid fototillfället och sedan använda detta värde vid RAW-konvertering.)

En mycket användbar teknik är att göra två RAW-"framkallningar" från samma fil; en där man justerar för högdagrar och en där man justerar för lågdagrar och sedan lägger samman. Skulle vilja påstå att man med hjälp av detta, samt givetvis noggrann exponering, i en del situationer kan vinna minst två steg, om inte mer, i exponeringsomfång, jämfört med en JPG som konverterats direkt i kameran.

Hmm... har aldrig lyckats hamna i den sitsen själv lyckligtvis, men om du i alla fall kommer till Single User Mode som du säger bör du kunna köra kommandot:

diskutil repairPermissions /

för att ställa saker och ting till rätta. Beroende på om kommandot finns i din sökväg eller inte kanske du istället får ange hela sökvägen istället:

/usr/sbin/diskutil repairPermissions /

Citerar www.bus.se som på ett bra sätt sammanfattar lagtexten gällande det som kallas den idéella rätten:

Vad gäller den idéella rättens förhandlingsbarhet backar jag ett steg tills jag hittar belägg för att den inte går att avsäga sig och säger istället bestämt att praxis är att man aldrig förhandlar bort sin idéella rätt, utan enbart begränsade delar av den ekonomiska. (Ex. avtalar man om att en bild får användas i en specifik publikation i ett visst antal ex.)

Egentligen vill jag här säga att fotografen alltid har sin idéella rätt, dvs alltid har rätt till sitt namn vid bilden, respekt för verket osv, men det är väl säkrast att jag nöjer mig med att konstatera att i princip inga avtal mellan fotografer och uppdragsgivare rör nånting annat än begränsad användning. Om INGA avtal finns är det alltid fotografen som har full rätt till bilderna, inte uppdragsgivaren.

För den som vill reda ut begreppen på egen hand finns lagtexten här

Som redan tidigare nämnts får vem som helst fotografera vem och vad som helst på allmän plats (utom skyddsobjekt). För att ett fotoförbud skall gälla i övrigt (på exempelvis privata anläggningar) måste detta informeras om på ett tydligt sätt, exempelvis med "Fotografering förbjuden"-skyltar, placerade väl synligt. Finns ingen sådan information är det faktiskt fritt fram. Däremot kan det ju då hända att precis som man fotograferar av hjärtans lust står man helt plötsligt öga mot öga med en arg ägare eller (än värre en biffig vakt som upplyser om att "Här får du minnsann inte ta några bilder!" Då är det bara att packa ner kameran, MEN, och här finns den lilla finessen, ingen har rätt att begära att få filmen eller att du raderar det du redan tagit från minneskortet. Man har med andra ord full rättighet till de bilder man tog innan man upplystes om fotograferingsförbudet.

Sammanfattningsvis kan alltså ett fotoförbud ALDRIG upprättas retroaktivt. Däremot gäller givetvis alla regler om publicering av personbilder som vanligt.

Vad gäller upphovsrättens förhandlingsbarhet så är den idéella rätten INTE möjlig att förhandla bort, enbart den ekonomiska.

Problemet är nog inte att QuickTime-pluginen inte klarar Motion JPEG utan troligare att videoströmmen inte anger rätt mime-typ (en curl -I visar nämligen: "Content-Type: multipart/x-mixed-replace"). Safari tror då att det är en fil den inte kan hantera och laddar helt enkelt ner den. Kolla i inställningarna för kameran om mime-typen kan ändras till något lämpligt, ex. video/x-motion-jpeg.

Den inbyggda brandväggen i Mac OS X (ipfw, urspr. från FreeBSD) är mycket bra (om än kanske inte riktigt lika vass som pf, som ju kommer från OpenBSD), det som brister är konfigureringsgränssnittet, vilket ju inte är gjort för annat än "hemanvändare". Med hjälp av tredjepartsprogram (eller manuell konfigurering) kan man skaffa sig obegränsad kontroll över sina brandväggsregler. Har man Mac OS X server har man också ett helt annat gränssnitt till samma brandvägg.

Ex. på tredjepartsprogram: Brickhouse (Shareware), sunShield (Freeware)

Sen är det klart att en fristående brandvägg blir smidigare när man lägger till maskiner i nätverket m.m. En OpenBSD-maskin med pf är ett mycket bra val, som dock kanske inte uppfyller kravet att vara lättkonfigurerad, men det är å andra sidan få professionellt driftade brandväggar som slängs upp i en handvändning. Det kan vara väl värt pengarna att ta hjälp av någon kunnig för att komma igång.

För de syften du nämner räcker den inbyggda ipfw till, och blir över. Använder ni dessutom Mac OS X server borde även det inbyggda grafiska gränssnittet räcka till.

Har läst att flaggan -o har hårdkodats i Panthers shutdown. Denna är odokumenterad i Apples man-sidor, men enligt FreeBSD-manualen indikerar den direkt anrop av reboot istället för att en signal skickas till init-processen. Flaggan -o kräver dessutom antingen -h eller -r, vilket gör att man inte längre kommer åt single-user-mode utan att starta om.

Mest av nyfikenhet undrar jag om det finns nån med insikt i Darwin-källkoden som kan svara på om denna förändring är nödvändig tills övriga delar av systemet fixas, eller om man skulle kunna kompilera sin egen shutdown. (Enligt vad jag läst infördes hårdkodningen för att init helt enkelt struntade i signalerna, men jag skulle hellre tvingas skriva -o själv än att inte kunna använda shutdown för att gå till su-mode.)